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Abstract 

This  research  describes  the  design  and  implementation  issues  associated  with  re¬ 
engineering  the  Air  Force  Institute  of  Technology  Student  Information  System 
(AFITSIS).  Currently,  AFITSIS  executes  on  aging  relational  database  technology  and  has 
unfriendly  user  interface  mechanisms.  The  two  research  objectives  met  were  to  research 
current  AFITSIS  requirements,  design,  and  implementation,  and  use  object-orient  methods 
to  design  an  alternative  implementation  based  on  proposed  object  database  management 
system  standards.  This  research  explores  how  AFITSIS  performance  and  capabilities 
might  be  enhanced  by  taking  advantage  of  new  object-oriented  software  engineering 
techniques.  One  of  the  primary  benefits  of  this  research  is  a  detailed  object  modeling 
technique  analysis  and  design  that  may  be  used  as  a  foundation  for  upgrading  the  current 
AFITSIS. 
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THE  RE-ENGINEERING  OF  THE  AIR  FORCE  INSTITUTE  OF 
TECHNOLOGY  STUDENT  INFORMATION  SYSTEM 

I.  Introduction 

Many  information  systems  suffer  from  old  technology  which  no  longer  adequately  meets 
the  needs  of  the  users.  The  Air  Force  Institute  of  Technology  Student  Information  System 
(AFITSIS)  is  such  a  system.  This  research  explored  how  AFITSIS's  performance  and  capabilities 
might  be  enhanced  by  taking  advantage  of  new  object-oriented  software  engineering  techniques. 

Background.  In  1987  the  Air  Force  Institute  of  Technology  (ART)  contracted  Systems 
Research  Laboratories,  Inc.  to  develop  an  automated  system,  called  the  Student  Tracking  and 
Registration  System  (STARS),  for  scheduling  courses,  registering  students  for  courses,  tracking 
students'  academic  histories,  and  generating  related  reports.  The  STARS  application  uses  the 
Structured  Query  Language  (SQL)  to  access  an  Oracle  Relational  Database  Management  System 
(RDBMS)  [21:1]. 

In  the  seven  years  since  the  initial  STARS  development  three  other  applications  have  been 
developed  (and  others  continue  to  be  developed)  sharing  tables  with  relevant  attributes  within  the 
RDBMS  [11].  This  group  of  applications  is  referred  to  as  AFITSIS  and  is  accessible  to  any  user 
with  a  designated  Username  and  Password  through  the  AFITNET  communications  network  [6]. 
In  addition  to  the  AFITSIS  applications  there  are  a  number  of  other  applications  that  share 
student-related  information  from  the  Oracle  RDBMS.  The  8-member  AFIT/SCV  organization  is 
responsible  for  providing  maintenance  and  upgrades  to  all  applications  as  requested  by  users  from 
all  administrative  offices  as  well  as  from  faculty  and  staff  of  AFTT's  schools  [11].  Planned 
expansion  of  AFTT's  educational  boundaries  for  the  Dayton  Area  Graduate  Studies  Institute 
(DAGSI),  to  include  Wright  State  University  and  the  University  of  Dayton  graduate  students,  will 
no  doubt  increase  the  requirements  of  the  current  DBMS. 
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Problem.  AFITSIS  is  currently  designed  and  implemented  upon  aging  relational 
database  technology  and  unfriendly  user  interface  mechanisms. 

Hypothesis.  AFITSIS  capabilities  and  performance  can  be  substantially  improved  by: 
(1)  redesigning  the  system  using  an  object-oriented  design  methodology,  (2)  converting  from  the 
relational  database  management  system  to  a  new  object-oriented  database  management  system, 
and  (3)  implementing  a  user  interface  in  a  Windows  environment.  These  steps  will  not  only 
provide  a  basis  for  an  improved  system  now,  it  will  also  aid  software  maintainers  faced  with 
adding  capabilities  in  the  future. 

Research  Objectives.  In  order  to  address  the  problem  stated  above  and  establish  the 
validity  of  the  above  hypothesis,  the  following  research  objectives  were  established: 

1.  Research  current  AFITSIS  requirements,  design,  and  implementation.  Document 
current  system  performance  benchmarks  and  maintainability  metrics  for  comparison  with  a 
prototype  system. 

2.  Use  object-oriented  methods  to  design  and  implement  an  object-oriented  database 
management  system  (OODBMS)  prototype  system.  Use  current  requirements  as  stated  by 
AFIT/SC  and  STARS  users  (performance  and  user  interface  requirements).  Create  the  design 
structure  with  possible  upgrades  in  mind. 

3.  Test  OODBMS  prototype  against  current  requirements.  Compare  performance 
benchmarks  and  maintainability  predictions  with  current  RDBMS. 

In  the  end,  a  working  prototype  proved  impractical  to  develop  as  a  part  of  this  thesis. 
However,  this  thesis  development  produced  detailed  design  information  adequate  for  a 
straightforward  prototype  development. 

Assumptions.  The  following  assumptions  were  made  during  the  thesis  effort: 

1.  Access  to  AFITSIS  database  and  query  information  is  available. 

2.  Access  to  an  OODBMS  is  available  for  use  with  the  prototype  to  be  developed. 
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3.  The  OODBMS  will  work  with  a  Windows-based  prototype. 

Assumption  two  proved  to  be  only  partly  true.  Ongoing  commercial  development  should 
soon  result  in  an  ODBMS  adequate  for  prototyping.  However,  the  currently  available  ODBMSs 
still  do  not  support  the  interface  standard  required  to  support  implementation  of  a  useful 
prototype. 

Sequence  of  Presentation.  The  thesis  is  divided  into  five  chapters.  Chapter  I, 
Introduction,  has  provided  an  overview  of  the  work.  Chapter  II,  Summary  of  Current 
Knowledge,  discusses  the  background  information  which  provides  the  foundation  for  this  thesis 
research.  Chapter  III,  Analysis  and  Design,  expands  in  detail  the  analysis  performed  by  designing 
an  Object  Modeling  Technique  (OMT)  model  for  this  research.  Chapter  IV,  Implementation 
Issues,  discusses  important  issues  relating  to  the  implementation  of  a  subset  of  the  object  classes 
contained  in  STARS.  Lastly,  Chapter  V,  Summary  and  Conclusions,  summarizes  the  results  of 
the  research,  draws  conclusions  from  the  summary,  and  makes  recommendations  for  future 


research  in  this  area. 


II.  Summary  of  Current  Knowledge 


Topic  Statement  and  Key  Terms.  This  literature  review  provides  the 
foundation  on  which  to  begin  the  re-engineering  and  improvement  of  AFITSIS.  AFITSIS 
is  a  software  database  application  used  by  AFIT  (orderly  room,  faculty,  administration, 
etc.)  to  query,  archive,  and  output  data  on  past  and  present  students,  faculty, 
administration  personnel,  curriculum,  schedules,  and  assignments  [21:1],  The  four 
applications  forming  AFITSIS  are  STARS,  QUEST,  CCQ,  and  ISA.  Their  fimctions  are 
described  briefly  below  [6]: 

STARS  maintains  AFIT  student  information  from  admittance  to  graduation. 

QUEST,  QUota  Education  and  Selection  Transactions,  tracks  information 
related  to  students'  selection  for  AFIT  or  Civilian  Institution  program,  and 
associated  Air  University  quotas. 

CCQ,  maintains  orderly  room  applicable  information,  such  as  box  numbers, 
locker  numbers,  sections  leaders,  security  access  badges,  building  access  cards, 
weigh-in,  aerobic  data,  weight  management  program  statistics,  emergency  locator 
information,  and  other  current  student  information. 

ISA,  International  Student  Affairs,  maintains  information  on  international 
students  attending  AFIT,  such  as  family,  funding,  sponsor,  and  program  data. 

Treatment  and  Organization.  The  Discussion  of  the  Literature  section  is 
divided  into  four  subsections  labeled  Object-Oriented  Methodology,  Relational  Databases, 
Object-Oriented  Databases,  and  OODBMS  versus  RDBMS.  The  Object-Oriented 
Methodology  subsection  describes  the  stages  used  by  the  developer  to  analyze  a  problem, 
design  a  system,  and  implement  the  system  into  a  usable  product.  The  Relational 
Database  subsection  is  required  to  understand  how  current  relational  systems  operate,  so 
AFITSIS  capabilities  may  be  provided  for  in  an  object-oriented  system.  The  Object- 
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Oriented  Database  subsection  discusses  engineering  features  important  to  developers  and 
the  system  functions  required  by  the  end  users.  Lastly,  the  OODBMS  versus  RDBMS 
subsection  outlines  the  facilities  that  will  be  required  for  the  next  generation  of  database 
technology. 

Discussion  of  the  Literature. 

Object-Oriented  Methodology.  Object-oriented  methodologies  allow 
developers  to  analyze  problems  and  divide  them  into  entities  residing  in  specific  states  and 
exhibiting  certain  dynamic  behaviors.  The  entities  become  objects  in  the  system.  The 
designer  further  defines  the  relationships  between  the  objects  to  determine  how  the  system 
functions  as  a  whole  [12:1-2].  The  object-oriented  methodology  used  in  this  research  is 
OMT  described  in  Object-Oriented  Modeling  and  Design  [19:4-6].  The  four  specific 
OMT  stages  are: 

1 .  Analysis.  During  the  analysis  stage,  the  developer  defines  the  system 
requirements.  Objects  are  identified  and  their  relationships  to  other  objects  are  recorded. 
Implementation  decisions  are  specifically  avoided.  OMT  recommends  defining  three 
models  during  analysis:  an  object  relationship  model,  a  dynamic  relationship  model,  and  a 
functional  model. 

2.  System  Design.  In  this  stage  the  system's  architecture  is  determined.  The 
application  is  broken  into  subsystems,  and  the  subsystems  into  sub-subsystems  (if 
required).  Resources  (such  as  storage,  processors,  etc.)  are  allocated  to  each  subsystem. 
Control  mechanisms  (procedural,  event-driven,  etc.)  are  defined  for  each  subsystem.  The 
overall  focus  is  on  what  needs  to  be  done,  independently  of  how  it  is  to  be  done. 

3.  Object  Design.  During  the  object  design  phase,  the  object  relationship  model, 
dynamic  model,  and  functional  model  are  evaluated  to  determine  what  operations  must  be 
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implemented  for  each  object.  Algorithms  for  these  operations  are  designed.  Structures 
for  representing  the  relationships  between  objects  are  defined. 

4.  Implementation.  The  final  stage  of  OMT  involves  transforming  the  design  into 
an  executable  system.  This  is  dependent  on  whether  the  software  language  selected 
supports  object-oriented  programming.  Chapter  IV  discusses  implementation  of  object 
models  from  the  student  tracking  and  registration  system  into  the  relational  database 
Structured  Query  Language  and  into  the  proposed  object  database  Object  Query 
Language  (OQL). 

Relational  Databases.  Traditional  database  applications  are  built  around 
relational  database  management  systems  where  data  is  stored  in  two-dimensional 
tables[2:45].  It  is  a  cumbersome  approach  in  which  data  has  two  distinct  representations 
between  in-memory  or  stored  on-disk.  The  DBMS  queries  and  shared  access  support  only 
record-based  disk  stored  data.  To  read  data  from  the  database,  the  programmer  needs  to 
allocate  a  buffer  and  issue  a  DBMS  query.  The  DBMS  selects  the  record  and  copies  it  to 
the  buffer.  The  programmer  treats  the  data  stored  in  the  buffer  as  though  it  is  an  instance 
of  the  programming  language  type  by  mapping  the  data  structure  declaration  for  the  type 
(within  the  program)  over  the  buffer.  Type  safety  is  lost  in  the  interface  and  problems  that 
may  arise  include,  buffers  that  are  too  small  or  too  large,  misaligning  the  overlaid 
template,  or  defined  template  fields  not  agreeing  with  the  record  representation  chosen  by 
the  database  [3:32-33]. 

Queries  returning  sets  of  records  require  a  cursor  mechanism  to  coordinate 
between  the  programming  language  runtime  and  the  DBMS  runtime  as  the  programmer 
iterates  through  the  resultant  set;  mapping  one  record  at  a  time  into  his  buffer.  Programs 
using  anything  more  complex  than  records  requires  the  programmer  to  write  code 
reassembling  the  database  records  into  the  program's  data  structure  [3:33].  All  of  this 
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requires  time  and  makes  relational  databases  less  desirable  for  many  real  world 
applications  [2:45], 

Relational  database  management  systems  are  derived  from  strict  mathematical 
concepts  [18: 162],  These  systems  evolved  to  support  such  common  database  features  as 
[16:425]; 

•  Uniformity,  Large  numbers  of  similarly  structured  data  items. 

•  Fixed  record  size.  Data  items  with  fixed  record  lengths;  approximately  the  same 
number  of  bytes. 

•  Small  data  items.  Records  rarely  larger  than  300  bytes  long. 

•  Atomic  fields.  Short  fixed-length  record  fields. 

•  Short  transactions.  Generally  little  or  no  human  interaction;  users  prepare 
transactions,  submit  for  execution,  and  await  the  outcome. 

•  Static  schemes.  Database  schemes  changed  infrequently  and  changes  are  simple, 
such  as  create  a  relation,  remove  a  relation,  add  attributes,  or  remove  attributes. 

These  features  make  relational  databases  less  capable  of  dealing  with  data  types 
not  easily  manipulated  with  conventional  functions,  such  as  those  used  in  manufacturing, 
engineering,  software  management,  and  document  management  [18:162].  The  new 
systems  require  the  ability  to  handle  evolving  features,  such  as  [16:426-427]; 

•  Complex  objects.  Objects  modeling  the  real-world  with  relationships  stored 
within  objects  and  nested  relationships  stored  within  relationships, 

•  Behavioral  data.  Objects  responding  to  the  same  command  in  different  ways. 

•  Meta  knowledge.  General  rules  of  the  application  which  maybe  represented  with 
the  database. 

•  Long-duration  transactions.  Those  seen  more  often  with  Computer-Aided 
Design  (CAD)  and  Computer-Aided  Software  Engineering  (CASE)  applications  where 
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human  interaction  often  leads  to  modification  of  design.  These  cause  transaction  aborts, 
waits  for  locks,  and  are  more  complex  than  short  duration  business-type  transactions. 

Object-Oriented  Databases.  Object-oriented  techniques  give  a  developer 
powerful  tools  to  define  requirements  and  translate  them  into  working  code.  These 
techniques  are  valuable  not  only  in  programming  languages,  but  also  in  defining  the  next 
generation  of  database  systems  -  object-oriented  databases  [4:33-34].  It  is  open  to 
discussion  as  to  what  precise  features  a  database  must  contain  to  be  considered  an  object- 
oriented  database.  One  author  maintains  an  object-oriented  database  management  system 
must  support  complex  objects,  unique  object  identifiers,  object  encapsulation,  data  types, 
inheritance,  persistence,  extendibility,  and  other  software  engineering  features  [1:27].  All 
of  these  software  engineering  features  are  invisible  to  the  database  management  system 
user,  but  are  important  in  supporting  the  database  management  systems'  main 
responsibilities:  sharing  files  among  users,  ensuring  data  integrity  and  recovery  with 
failures,  distributing  data  in  a  network,  and  managing  the  search  through  large  amounts  of 
data  [2:44-45]. 

Two  years  ago  in  an  effort  to  establish  an  industry-wide  agreement  for  object- 
oriented  database  technology  a  consortium  of  object-oriented  database  companies  formed 
the  Object  Database  Management  Group  (ODMG).  This  group  of  technical  experts 
published  The  Object  Database  Standard:  ODMG-93  which  defines  a  standard  for  object 
database  management  systems  [5:1-15],  This  standard  is  referred  to  throughout  the 
remainder  of  the  text  as  the  ODMG-93  standard  or  simply  ODMG-93.  The  primary  goal 
of  ODMG-93  was  to  introduce  proposed  standards  allo-wing  portable  applications  to  be 
written.  For  this  goal  to  be  achieved  the  data  schema,  programming  language  binding, 
data  manipulation,  and  data  query  languages  must  be  portable.  This  goal  of  source  code 
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portability  makes  database  objects  appear  as  programming  language  objects,  in  one  or 
more  existing  programming  languages  [5:2-3], 

OODBMS  versus  RDBMS.  For  the  past  three  decades  applications  have 
grown  in  fimctionality,  and  the  cost  of  implementing,  maintaining,  and  extending  them  has 
risen  while  software  has  evolved  through  four  generations  of  database  technology:  file, 
hierarchical,  CODASYL,  and  relational.  The  evolution  of  computer  applications  and 
database  technology  requires  a  management  system  that  can  meet  both  today’s  and  newly 
emerging  requirements.  Since  the  late  1970s  relational  products  have  handled  most 
conventional  information  systems  applications,  but  appear  not  as  adept  for  new  and  future 
information  system  needs.  These  applications,  such  as  computer-aided  design, 
engineering,  and  manufacturing  software  systems,  require  the  ability  to  create,  access, 
manipulate,  and  save  large  amounts  of  persistent  data  as  well  as  be  available  to  a  large  and 
diverse  number  of  users.  The  next  generation  of  database  technology  must  build  upon  the 
conventional  database  technologies  meeting  today’s  requirements  and  exploit  current 
technology  to  meet  the  growing  new  requirements.  The  database  technology  must 
provide  the  capabilities  required  by  conventional  information  systems  before  they  can 
successfully  evolve  to  the  fifth  generation  database  technology  [14:35-36], 

The  two  contending  database  technologies  to  capture  this  next  generation  appear 
to  be  extended  relational  database  technology  and  object-oriented  database  technology. 
The  extended  relational  approach  extends  the  current  relational  model  of  data  and 
provides  a  query  language  to  broaden  the  applicability  of  the  model  without  sacrificing  the 
relational  foundation.  Extended  relational  data  models  allow  recursive  queries,  relations 
that  are  not  in  first  normal  form,  complex  objects,  and  the  combining  of  logic-base  rules 
with  triggers.  The  object-oriented  approach  starts  with  an  object-oriented  data  model  and 
a  language  that  captures  it  and  extends  them  so  that  database  objects  appear  as 
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programming  language  objects.  Experts  argue  over  the  capabilities  and  liabilities  of  the 
extended  relational  approach  versus  object-oriented,  but  conventional  wisdom  suggests 
that  both  approaches  will  coexist.  The  potential  savings  in  development  and  maintenance 
of  the  object-oriented  technology  seems  to  be  balanced  by  the  widespread  use  of  long-held 
relational-based  applications  [14:35-36]. 

An  object-oriented  database  system  is  a  persistent  and  shareable  repository  and 
manager  of  an  object-oriented  database  —  itself  a  collection  of  objects  defined  by  an 
object-oriented  data  model.  A  data  model  is  a  logical  organization  of  real-world  entities. 
Object-oriented  concepts  form  a  good  basis  for  developing  a  rich  data  model  for  next- 
generation  database  applications.  There  is  no  standard  data  model  on  which  to  construct 
an  object-oriented  database  language  from  which  to  program  applications  [14:36-40]. 

Won  Kim  proposes  a  set  of  rules  to  define  object-oriented  database  systems.  First, 
an  object-oriented  database  system  must  provide  all  conventional  database  facilities. 
Second,  an  object-oriented  database  systems  must  allow  the  following  [14:36-40]: 

•  Real  world  entities  must  be  modeled  as  objects  with  a  unique  identifier  for  each 

object. 

•  Every  object  must  have  a  state  and  a  behavior  (attributes). 

•  Objects  may  be  grouped  into  classes  according  to  attributes  and  methods. 

•  A  class  attribute’s  domain  (type)  may  be  a  class. 

•  Classes  must  be  organized  into  a  rooted  directed  acyclic  graph  or  hierarchy. 

•  An  object’s  state  and  behavior  can  only  be  accessed  or  invoked  from  outside  the 
object  through  an  explicit  message. 

Kim  maintains  that  these  concepts  form  the  basis  of  any  viable  object-oriented  data 
model,  and  any  database  language  that  would  evolve.  The  three  components  of  a  database 
language  are  data  definition,  data  manipulation,  and  data  control.  The  first  component. 
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data  definition  allows  a  programmer  to  specify  a  database  schema  or  framework.  In  an 
object-oriented  database  a  specification  will  define  the  interfaces  to  object  types  as 
described  in  the  object  model.  The  ability  to  treat  any  real  world  entity  as  an  object 
simplifies  the  user’s  view  of  the  world.  Object  identifiers  are  important  to  object-oriented 
systems  because  objects  consist  of  attributes  with  values,  and  the  system  (as  well  as 
object-oriented  languages)  assume  objects  exist  in  a  large  virtual  memory.  The  class 
concept  is  important  to  object-oriented  database  systems  because  it  captures  semantic 
data-modeling  concepts  (relationships),  it  is  the  base  on  which  queries  may  be  formed,  it 
enhances  integrity  by  virtue  of  type  checking,  and  allows  sharing  of  attributes  and  methods 
[14:42]. 

The  second  database  language  component,  data  manipulation  provides  facilities  to 
express  queries  and  updates  to  a  specified  database.  The  object-oriented  database  must 
allow  users  to  [15:33]: 

•  Create,  update,  and  delete  individual  instances  of  a  class. 

•  Fetch  an  object  using  the  object’s  unique  identifier,  or  a  collection  of  objects 
rooted  at  a  user-specified  object  (navigational  fetch). 

•  Fetch  a  set  of  objects  satisfying  user  specified  search  conditions  (declarative 

fetch). 

•  Allow  queries  on  a  single  class  and  queries  on  more  than  one  class. 

The  third  database  language  component,  data  control,  provides  integrity  protection 
of  the  database  and  manages  system  resources.  The  data  control  must  allow  specification 
of  transactions  (commit  and  abort),  semantic  integrity  control  (class  methods), 
authorization  (limit  access),  and  management  of  access  methods  [15:36]. 
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According  to  John  Joseph  and  associates,  the  five  principle  reasons  that 
conventional  databases  are  inadequate  in  serving  the  needs  of  the  next  generation 
applications  are  [13:46-47]: 

1)  Lack  of  expressive  data  modeling.  Next-generation  applications  require  the 
same  level  of  expressive  power  as  programming  languages,  such  as  complex  data  types 
(arrays,  records,  class  definitions,  and  fianctions)  or  control  structures  (conditional  clauses 
and  procedure  calls). 

2)  “Impedance  mismatch”  between  programming  languages  and  database  systems. 
Impedance  mismatch  is  the  difference  between  the  programming  languages  required  to 
support  differing  data  models  and  paradigms  for  object  manipulation.  This  mismatch 
decreases  application  programmer  productivity  by  requiring  complex  problems  to  be 
mapped  to  the  conventional  database.  The  mismatch  also  requires  programmers  to  use 
two  programming  languages  and  paradigms  in  the  two  environments. 

3)  Interactive  performance  does  not  support  next  generation  applications.  The 
expense  of  a  relational  query  to  fetch  a  single,  identified  object  is  too  high  because  it  often 
requires  burdensome  overhead  when  compared  with  the  simple  offset  addressing  of  an 
object-oriented  database. 

4)  Lack  of  mechanisms  to  support  long  transactions.  Long  transactions  require 
cooperative  transactions,  in  contrast  to  the  short  duration  of  conventional  database 
transactions  locking  very  little  data  and  involving  infrequent  locking  conflicts. 

5)  Lack  of  mechanisms  to  support  schema  evolution  and  version  management.  By 
conventional  thinking  databases  only  have  a  single  state  —  the  current  state;  there  is  no 
version  management. 

Conclusion.  In  conclusion,  this  literature  review  has  provided  an  overview  of  the 
Object  Modeling  Technique,  presented  limitations  of  a  relational  database  system,  and 
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discussed  the  engineering  features  of  object-oriented  databases  to  support  database  system 
functions.  All  three  of  these  areas  are  required  for  the  successfiil  analysis  and  re¬ 
engineering  of  the  AFITSIS. 
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III.  Analysis  and  Design 


Introduction.  This  chapter  presents  the  steps  necessary  to  construct  an  analysis 
model  and  the  process  in  building  the  subsequent  design  model  for  STARS  as  a  proof  of 
concept  for  this  research.  The  approach  includes  the  use  of  the  analysis  process  presented 
with  the  Object  Modeling  Technique  (OMT)  as  documented  in  Object-Oriented  Modeling 
and  Design,  by  Rumbaugh  and  associates,  and  pictured  in  Figure  3 . 1  [  1 9 : 1 49] .  To 
maintain  the  distinction  between  the  analysis  model  and  design  model  it  is  useful  to 
remember  the  following  general  definitions.  The  analysis  model  includes  information 
meaningful  to  the  client  of  the  system;  it  is  an  external  view  of  the  system.  The  design 
model  is  constructed  for  computer  implementation;  it  must  be  efficient  and  practical  to 
encode. 


User  Interviews 
Domain  Knowledge 
Real-World  Experience 

Object  Model 
Dynamic  Model 
Functional  Model 


Design 

Figure  3.1  Overview  of  the  analysis  process  (Rurabatigh  and  others,  p.  149). 
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Although  many  courses  and  research  revolve  around  object-oriented  programming 
languages  and  coding,  Rumbaugh  and  associates  emphasize  from  the  beginning  that  OMT 
applies  to  a  system’s  entire  software  development  cycle.  The  OMT  cycle  begins  with  the 
analysis  of  a  system  problem  statement  and  continues  until  the  end  of  the  software 
system’s  life-cycle.  The  results  from  the  analysis  phase  is  carried  forward  to  system  and 
object  design.  Finally,  the  results  are  used  by  software  programmers  to  implement  the 
final  system.  The  key  part  of  this  whole  process  are  the  three  models  -  object,  dynamic, 
and  functional.  Although  developed  at  the  beginning  of  the  process  from  the  problem 
statement,  all  three  models  undergo  constant  scrutiny  and  revision  from  start  to  finish  and 
in  effect  become  extremely  valuable  documentation,  not  only  for  the  system  designers,  but 
also  the  maintainers  late  in  the  software’s  life-cycle. 

Analysis.  The  OMT  approach  was  followed  in  this  paper  and  begins  with  the  a 
simple  problem  statement  upon  which  three  models  are  constructed  to  capture  the  system 
from  three  related  but  differing  viewpoints.  The  three  models  as  introduced  in  chapter 
two  are;  the  object  model,  the  dynamic  model,  and  the  functional  model.  The  object 
model  captures  the  static,  structural,  or  “data”  aspects  of  the  system.  The  dynamic  model 
captures  the  behavioral,  or  “control”  aspects  of  the  system.  The  functional  model 
captures  the  transformational,  or  “functional”  aspect  of  a  system.  Systems  developed 
under  such  an  approach  may  rely  heavily  upon  one  or  more  aspects  of  the  three  models 
depending  upon  software  requirements.  For  example,  in  the  database  portion  of  the 
STARS  software  where  data  persistence  and  manipulation  are  the  main  focus,  the  object 
model  is  the  most  important  model.  The  object  model  shows  which  objects  are 
responsible  for  what  data  (attributes)  and  how  the  different  objects  are  related  with  one 
another  (relationships).  The  object  model  is  followed,  in  importance,  by  the  dynamic 
model  which  shows  concurrent  access  of  distributed  information,  and  may  be  used  to 
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estimate  transaction  throughput.  The  functional  model  is  less  important  because 
operations  are  usually  predefined  and  tend  to  focus  on  creating,  updating,  and  querying 
information  [19:148-149], 

The  following  sections  outline  the  creation  of  the  analysis  model  beginning  with 
the  problem  statement,  detailing  construction  of  the  object,  dynamic,  and  functional 
models,  and  discussing  the  final  analysis  of  the  three  models. 

Problem  Statement.  The  maintainers  and  users  of  the  current  system, 
along  with  development  documentation,  provided  the  requirements  necessary  to 


The  Student  Tracking  and  Registration  System  (STARS)  should  be  designed  for  use  by  students,  faculty,  and  administration 
persotmel.  The  system  shall  distinguish  between  authorized  and  unauthorized  users.  Among  authorized  users  operations  shall  be  granted 
depending  upon  their  authority.  For  example,  faculty  and  administrative  personnel  will  have  privileges  that  a  student  will  not. 

The  database  system  will  perform  such  typical  operations  as: 

a.  creating  data, 

b.  storing  persistent  data, 

c.  retrieving  data, 

d.  editing  data,  and 

e.  deleting  data. 

The  database  system  will  save  information  relevant  to  students,  instructors,  dependents  of  military  members,  and  sponsors  of  research 
areas.  The  system  will  also  track  school  and  course  registration  data,  such  as  course  sections,  class  rosters,  grades  assigned,  GPAs,  etc,  A 
user  will  log  into  the  database  application  and  be  provided  operation  choices.  Only  those  functions  for  which  the  user  has  authorization 
will  be  offered.  Typical  user  queries  will  be  provided.  For  example,  the  user  should  be  able  to  view  and  output  the  courses  scheduled  for  a 
particular  quarter  including  instructors,  times,  days,  and  assigned  room(s).  Queries  will  be  possible  on  a  student’s  overall,  planned, 
completed,  and  present  schedules.  Modifications  shall  be  allowed  on  planned  and  current  schedules  by  proper  personnel.  Modifications  to 
course  grades  will  only  be  allowed  by  authorized  authority.  Access  to  database  information  for  purposes  of  printing  or  viewing  should  be 
allowed  concurrently  by  any  number  of  users.  Access  to  data  being  created  or  modified  should  prevent  other  users  from  accessing  and/or 
modifying  the  information  at  the  same  time.  Historical  records  must  be  maintained  for  changes  to  certain  database  fields  (i.e.  SS  AN,  Name, 
Rank,  Program,  Graduation  Date), 


Figure  3.2  Student  Tracking  and  Registration  System  Problem  Statement 

implement  a  system,  as  well  as  fixture  requirements  for  anticipated  growth.  From  this 
foundation  a  STARS  problem  statement  was  formed  as  shown  in  Figure  3.2. 
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Object  Model.  The  object  model  describes  the  identity,  relationships, 
attributes,  and  operations  of  objects  in  a  system.  An  object  model  was  constructed  by 


[19:21-47]: 

i)  identifying  objects  and  classes  from  the  problem  statement, 

ii)  identifying  associations  between  objects, 

iii)  identifying  attributes  of  the  objects  and  links, 

iv)  verifying  access  paths  exist  for  queries,  and 

v)  refining  the  object  model  with  numerous  iterations. 

Identify  Object  Classes.  All  relevant  objects  were  identified  from 
the  database  domain.  Explicit  object  classes  are  the  easiest  to  identify  by  extracting  the 
nouns  present  in  the  overall  requirements  statement.  Figure  3.3  lists  the  tentative  object 
classes  obtained  from  the  requirements  statement. 


authorized  users 

students 

unauthorized  users 

database  system 

data 

personnel 

records 

instructors 

students 

grades 

database  system 

courses 

persistent  data 

rooms 

instructors 

authority 

dependents 

application 

military  members 

operation 

sponsors 

functions 

research  areas 

historical  records 

schedule 

26  menus  (main  menu/25  submenus) 

planned  schedule 
present  schedule 

completed  schedule 

Figure  3.3  Candidate  object  classes 

Additional  implicit  classes  are  not  as  easy  to  identify  and  must  be  obtained  by  knowledge 
of  the  problem  domain.  The  implicit  object  classes  such  as  forms,  international  students. 
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and  departments  were  derived  from  interviews  with  the  maintainers  and  development 
documentation. 

Object  classes  were  eliminated  from  the  candidate  list  for  the  following  reasons; 

a)  Redundant  classes  expressing  the  same  information.  Duplicate  classes  of 
students,  database  system,  and  instructors  may  be  eliminated. 

b)  Irrelevant  classes  having  nothing  to  do  with  the  problem.  Personnel  does  not 
adequately  describe  the  object  class  and  is  replaced  with  person. 

c)  Vague  classes  too  broad  in  scope.  Records,  historical  records,  data,  and 
persistent  data  all  describe  the  information  we  wish  to  maintain  through  the  use  of 
objects’  specific  attributes. 

d)  Classes  that  are  attributes  of  another  class.  Grades  are  attributes  of  a  person 
class  or  an  attribute  of  the  relationship  between  a  person  and  a  course. 

e)  Class  is  an  operation  of  another  class.  Functions  and  operations  are  too  general 
to  implement  and  will  become  specific  object  functions  or  procedures  during  design  and 
implementation. 

f)  Implementation  construct.  Authority  will  be  decided  during  implementation;  it 
could  also  be  viewed  as  an  attribute  of  a  user  of  the  application. 

The  result  of  identifying  object  classes  is  documented  in  a  data  dictionary 
identifying  each  class  and  describing  its  relationship  to  the  problem  being  modeled.  The 
data  dictionary  for  the  STARS  object  model  is  provided  in  Appendix  A.  Current  object 
classes  are  depicted  in  Figure  3.4. 
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DEPARTMENT 


SCHOOL 


PERSON 


Figure  3.4  Current  Object  Classes 


Identify  Associations.  Next,  all  dependencies  were  identified 
between  two  or  more  classes  and  documented  as  associations  between  classes.  Figure  3.5 
lists  all  candidate  associations  fi'om  the  problem  statement  and  problem  domain.  Explicit 
associations  can  usually  be  identified  as  verbs  or  verb  phrases  within  the  problem 
statement.  Other  associations  were  identified  from  user  documentation  or  as  part  of  the 
inherit  problem  domain. 
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Verb  Phrases: 

distinguish  between  authorized  or  unauthorized  user 

save  information 

distinguish  among  : 

provide  menus 

1 .  Student  User 

store  persistent  data 

2.  Faculty  User 

retrieve  data 

3.  Administrative  User 

edit  data 

query  student  schedules 

create  data 

modify  schedules 

delete  data 

printing  or  viewing  by  any  number  of  users 

log  into  application 

limit  user  access  for  creating  and  modifying 

modify  grades 

perform  authorized  functions 

access  database 

maintain  historical  records 

Implicit  Verb  Phrases: 

faculty  may  be  either  civilian  or  military  persons 

faculty  are  a  type  of  person 

students  may  be  either  civilian  or  military  persons 

students  are  a  type  of  person 

dependents  are  a  type  of  person 

sponsors  are  a  type  of  person 

international  students  are  a  type  of  person 

Knowledge  of  Problem  Domain: 

faculty  teach  courses 

students  take  courses 

faculty  advise  students  academically 

courses  require  book(s) 

faculty  advise  thesis  students 

sections  meet  in  rooms 

faculty  are  members  of  theses  committees 

courses  require  prerequisites 

sections  are  offered  by  quarter 

courses  are  taught  as  sections 

curricula  are  made  up  of  courses 

rooms  are  part  of  buildings 

students  write  theses 

Figure  3.5  Candidate  Associations 


Identify  Attributes.  Attributes  were  identified  by  consulting  the 
STARS  Users  Manual  and  a  listing  of  the  151  relational  tables  in  the  current  AFITSIS 
database  system.  Appendix  B  provides  the  menus  and  possible  operations  as  depicted  in 
the  STARS  Users  Manual,  and  the  relational  tables  with  fields  fi-om  the  current  system. 
As  an  example,  Figure  3.6  is  a  current  relational  table  in  the  AFIT  database  used  by 
STARS  to  represent  a  Person.  Attributes  that  could  be  used  to  represent  characteristics 
of  a  person  class  could  be  social  security  account  number,  grade/rank,  name  prefix,  first 
name,  last  name,  middle  initial,  date  of  birth,  etc. 
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Person  (  SSAN,  Grade  Rank  Abbrev,  Name  Prefix,  Name  Suffix,  First  Name,  Last  Name, 
Middle_Initial,  Birth  Date,  Sex  Code,  Race  Code,  Marital  Status  Code,  Religion  Code, 
Blue  Chip  Indicator,  Aka  FName,  Aka  LName,  Prior  AFIT  Months,  TAFMS  Date, 
Ethnic  Group  Code,  Aero  Rating  Code,  Maniung  Code,  DEROS  Date,  Separation  Date, 
Commission  Code,  Grade_Rank_Date,  CitizenshipOOCountry  Code,  Department  Code, 
Duty  Title,  Duty_Phone,  Duty  Area  Code,  Badge  Number,  Branch  Service  Code, 

Login  Name,  Input  Pate,  Duty  Phone  Ext ) _ 

Figure  3.6  Relational  table  for  Person 


The  object  classes,  relationships,  and  attributes  identified  in  the  sections  above  were  then 
arranged  in  the  object  diagrams  pictured  as  part  of  the  Data  Dictionary  at  Appendix  A. 
Figures  3.7  through  3.12  exhibit  basic  object  modeling  concepts  (without  object  class 
attributes)  used  in  development  of  the  final  object  diagrams. 


pursue 

DEGREE  - 

- •  STUDENT 

pur8uecl_by 

pursues 

Figure  3.7  One-to-many  Association 


The  one-to-many  association  in  Figure  3.7  captures  the  relationship  between 
Degree  and  Student.  A  degree  is  pursued  by  many  students,  or  the  inverse  relationship  of 
a  student  pursuing  a  degree. 


Figure  3.8  Ternary  Association 
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The  ternary  association  in  Figure  3.8  shows  the  Student  registration  relationship 
with  Quarter  and  Section  object  classes.  A  student  may  be  enrolled  in  multiple  quarters 
and  multiple  sections.  A  quarter  will  have  many  students  registered  for  multiple  sections. 
Finally,  a  section  will  be  offered  in  specific  quarter(s)  and  enroll  a  number  of  students. 


Figure  3.9  Inheritance 


Figure  3.10  Multiple  inheritance 

The  inheritance  and  multiple  inheritance  object  diagrams  shown  in  Figures  3.9  and 
3.10  model  the  different  types  of  people  within  the  school. 


3-9 


Figure  3.11  Association  with  link  attribute 


The  link  attributes,  shown  in  Figure  3. 1 1,  on  the  schedule  Jor  association  between 
Section  and  Building  captures  attributes  unique  to  the  relationship  between  the  two 
objects. 


Figure  3.12  Aggregation 


The  aggregation  modeled  in  Figure  3.12  depicts  the  Building,  Department,  and 
Person  objects  necessary  to  construct  the  school  object. 

Access  Paths  for  Likely  Queries.  One  way  to  verify  that  the 
object  diagrams  obtained  thus  far  are  accurate  is  to  trace  access  paths  through  the  object 
model  to  see  if  they  yield  sensible  results.  One  would  assume  when  a  user  to  the  STARS 
entered  the  application  that  they  would  have  a  particular  interest  in  mind  for  the  data. 

This  would  probably  be  creating,  modifying,  displaying,  or  deleting  records  or  data.  Paths 
for  likely  queries  would  be  to  obtain  information  from  one  of  the  objects  (such  as  a 
student’s  GPA)  or  to  be  able  to  obtain  relationships  between  objects  (such  as  a  list  of 
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classes  being  taken  by  a  student  for  a  particular  quarter).  The  object  model  in  the  STARS 
database  contains  a  large  number  of  possible  queries  depending  upon  the  user  and  the 
interests  in  the  data.  An  administrative  user  may  wish  to  know  how  many  students  were 
enrolled  per  department  for  the  last  ten  years.  Registration  personnel  may  be  interested  in 
whether  all  student  records  are  complete  and  up  to  date.  Student’s  may  be  interested  in 
their  schedules  for  past,  present,  and  future  quarters.  Faculty  members  may  be  concerned 
with  inputting  the  final  grades  for  the  quarter.  No  matter  what  the  intent  of  the  user,  the 
application  needs  to  access  the  database  and  provide  the  function  requested  by  the  user. 

Because  of  the  large  number  of  queries  possible,  the  implementation  of  the  proof 
of  concept  for  this  thesis  focuses  on  a  user  viewing  a  class  roster  and  a  student’s  schedule. 

Refine  Object  Model.  Refining  the  object  model  is  a  continuous 
process  of  iteration,  not  just  during  the  object  modeling  phase,  but  at  every  stage  of  the 
analysis  and  design  process.  Object  classes  that  are  found  to  be  needed  during  later  stages 
of  the  analysis  process  need  to  be  incorporated  into  the  object  model  at  that  time. 

Complex  object  models  can  be  grouped  by  classes  into  modules  which  represent  some 
logical  subset  of  the  entire  model. 

Dynamic  Model.  The  dynamic  model  shows  the  time-dependent  behavior 
of  a  system  and  objects  within  it.  A  dynamic  model  for  STARS  was  constructed  by 
[17:84-113]: 

i)  preparing  scenarios  of  typical  interaction  sequences, 

ii)  identifying  events  between  objects, 

iii)  preparing  an  event  flow  diagram  for  the  system, 

iv)  building  state  diagrams  and  state  transition  tables,  and 

v)  matching  events  between  objects  to  verify  consistency. 

Scenarios.  Scenarios  were  created  to  better  understand  typical 
exchanges  between  a  user  and  the  system.  Two  scenarios  for  the  student  tracking  and 
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registration  system  are  presented.  First,  a  faculty  user  scenario  (Figure  3.13)  describes  the 
steps  an  instructor  uses  to  print  out  a  class  roster.  Figure  3.14  depicts  the  second  scenario 
of  an  administrative  user  creating  a  new  instance  of  a  student.  (Note:  the  second  scenario 
only  considers  the  steps  changed  from  the  first  scenario.) 


The  user  starts  Window  application. 

The  application  requests  user  name  and  password;  the  user  enters  name  and 
password. 

The  application  verifies  user  name  and  password  with  database  system;  system 
recognizes  authorized  user  (as  type  faculty)  and  notifies  application. 

The  application  presents  faculty  user  with  menu  of  operations  (view  student 
schedule,  print  student  schedule,  view  faculty  schedule,  print  faculty 
schedule,  view  class  roster,  print  class  roster, ...);  the  user  selects  print 
class  roster. 

The  application  asks  user  to  identify  the  class  by  section  and  quarter;  the  user 
identifies  class. 

The  application  sends  system  roster  request. 

The  system  passes  application  the  requested  class  roster. 

The  application  prints  class  roster. 

The  application  presents  user  with  menu  of  operations;  user  selects  exit. 

The  application  terminates. _ 

Figure  3.13  Faculty  User  Scenario 


The  first  three  steps  are  the  same  as  Figure  3.13  above. 

Application  presents  administrative  user  with  menu  of  operations  (create 
student,  create  faculty,  modify  student,  modify  faculty,  delete  student, 
delete  faculty, ...);  the  user  selects  create  new  student. 

The  application  sends  system  create  new  student  request. 

The  system  presents  application  with  a  blank  form  to  be  filled  out  by  user. 

The  user  fills  in  form  (student’s  last  name,  first  name,  middle  initial,  SSAN, ...) 

The  user  submits  data. 

The  application  passes  data  to  system. 

The  application  presents  administrative  user  with  menu  of  operations;  the  user 
selects  exit. 

The  application  terminates. _ 

Figure  3.14  Administrative  User  Scenario 


3-12 


Events  Between  Objects.  Events  to  and  from  a  typical  user 
and/or  any  external  devices  were  identified  from  the  two  scenarios  in  Figures  3.13  and 
3.14.  Event  traces  were  constructed  from  the  scenarios  described  exhibiting  the  events 
that  arise  between  the  objects  of  different  classes.  The  user  in  Figures  3.15  and  3.16 
represents  a  person  being  queried  for  information  and  responding  to  the  requests. 
Although  not  shown  on  these  event  traces,  error  conditions  and  unusual  events  need  also 
to  be  considered  when  listing  all  possible  events  between  objects. 


User  Application  Database  System 


start  application  ^ 

verify  name  and  password  ^ 

^  request  name 

enter  name  ^ 

^  request  password 

enter  password  ^ 

^  present  options  menu 

^  authorized  feculty  user 

^  Forms 

And  query  paramel^  I 
j^urn  query  parameters; 

1 

request  data  (class  roster)  ^ 

enter  selection  (print  roster)  ^ 

^  request  section  and  quarter 

enter  section  and  quarter  ^ 

^request  number  to  be  printed 

^  return  data  (class  roster) 

, 

enter  number  ^ 

^  print  ciass  roster 

^  present  options  menu 

enter  selection  (exit)  ^ 

Figure  3.15  Event  trace  for  faculty  user  scenario 
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User 


Application 


Database  System 


present  options  menu 


enter  selection  (create  student^ 

^  request  data  entry 

enter  data 

commit  (student) 

^  present  suboptions  menu 

enter  subselection  (main  menu 


Forms 

find  query  paramet^^j 


rn  query  parameters 


check  If  data  exists 


boolean  (false) 


save  (student)  data 


“student  data  saved” 


Figure  3.16  Event  trace  for  administrative  user  scenario 


request  name 
request  password 
present  options  menu 
request  query  data 
request  number  to  print 
request  data  entry 
print  form  (with  data) 


verify  name  and  password 


request  suboption  selecton 

User 

Application 

Database 

System 

start  application 

— 1 - X — 

return  user  tvoe  ffacuitv.  admin,  student) 

enter  password 
enter  selection 

(print  roster,  create  student,  view  schedule,  exit) 
enter  query  data 
enter  number  to  print 

enter  suboption  selection  (commit,  cancel,  repeat) 


request  form } 


return  data  (class  roster,  student  schedule,  student  data) 
return  boolean 


provide  form 


Forms 


Figure  3.17  Event  flow  diagram  for  scenarios 


Event  Flow  Diagrams.  The  event  flow  diagram  in  Figure  3.17 
summarizes  the  events  between  classes  without  regard  to  sequencing.  The  event  flow 
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diagram  shows  the  information  flow  and  serves  as  a  dynamic  counterpart  to  an  object 
diagram. 

State  Diagrams.  The  next  step  in  dynamic  modeling  is 
constructing  state  diagrams  for  each  object  class  with  nontrivial  dynamic  behavior 
showing  the  events  that  the  object  receives  and  sends.  Every  scenario  corresponds  to  a 
path  through  the  state  diagram.  A  single  object  was  considered  and  arranged  with  arrows 
labeling  the  input  and  output  events  from  one  state  to  the  next.  The  intervals  between  two 
events  can  be  considered  a  state.  Merging  states  and  events  from  other  scenarios  provides 
alternative  paths,  and  traversal  loops  that  allow  scenarios  to  have  differing  outcomes  when 
traversed  in  different  permutations. 

The  state  diagram  process  began  by  modeling  the  application  object  in  its  simplest 
form  -  either  Idle  (following  application  start-up)  or  In  Use  (beginning  when  the  user 
logs-in  and  ending  with  either  an  invalid  login  or  program  exit).  At  this  high  level,  the 
application  is  either  Idle  or  InJUse.  Following  application  start-up  a  user  could  enter  a 
name,  fail  user  authorization,  in  which  case  the  application  will  return  to  the  Idle  state,  or 
use  the  application  and  then  exit. 

All  four  of  the  events  are  shown  in  the  state  diagram  of  Figure  3.18  below. 
StartApplication  begins  the  diagram  (represented  with  the  single  solid  dot)  and  the 
[EXIT]  criteria  ends  the  flow  through  the  state  diagram  (represented  with  the  circled  solid 
dot). 


UserLogjn(name) 


StartApplication 

[EXIT] 

IDLE 

do:  offer  login 

IN_USE 
do:  work 

LoginInvalidrLogin  Denied" 

Figure  3.18  Application  state  diagram 
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The  InJUse  state  in  Figure  3.18  can  be  modeled  with  three  substates  identified 
fi'om  the  event  trace  diagrams  (Figures  3.15  and  3.16).  Figure  3.19  shows  the  three 
substates  {Process  Login,  Present  Options  Menu,  and  Process  Selection)  and  the  events 
triggering  movement  from  one  state  to  the  next. 


[EXIT] 


[EXIT] 


Figure  3.19  Substates  of  In_Use  state 


Figure  3.20  shows  the  Present  Options  Menu  state  as  a  dependent  state  on  the 
guard  variable  user  type.  The  type  of  user  identified  during  the  Process  Login  state  will 
dictate  the  menu  options  offered  to  the  user.  The  three  different  types  of  users, 
administrative,  faculty,  and  student,  will  have  an  assortment  of  options,  some  of  which 
may  or  may  not  be  the  same  as  those  offered  to  another  type  of  user. 
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Figure  3.20  Present  Options  Menu  state  as  dependent  state 


The  modeling  of  the  menus  and  submenus  presents  an  interesting  relationship 
between  the  two  types  of  menus.  A  submenu,  in  general,  is  a  lower  tiered  menu  from  the 
main  menu.  The  main  menu  will  contain  a  list  of  options  from  which  a  user  selects. 

Menus  may  have  a  title  and  a  list  of  options  from  which  to  make  a  selection.  The  first 
option  of  the  menu  will  be  the  default  selection.  Only  those  options  for  which  the  user  has 
authorization  will  be  displayed  as  menu  options. 


[FALSE][PRINT]/"Data  Does  Not  Exist’ 


Figure  3.21  Partial  substates  for  Process  Selection  state 
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The  Process  Selection  substate  shown  in  Figure  3.21  is  further  broken  down  into 
states  required  to  handle  the  Print  class  roster  request  made  by  the  faculty  user  in  the 
earlier  scenario  (Figure  3.13).  The  substates  for  the  Process  Selection  state  consist  of 
finding  the  type  of  form  involved  with  the  users  request,  using  query  data  (in  this  case  a 
person’s  SSAN)  to  see  if  the  objects  exist,  and  if  the  answer  is  true  then  the  request  is 
executed.  If  the  answer  is  false  then  the  user  is  notified  and  the  application  waits  for 
another  request. 

A  form  is  a  screen  display  of  a  printed  document.  It  may  be  in  a  fill-in-the-blank 
format  and  designed  to  a  level  where  the  user  need  not  have  any  programming  skills.  The 
purpose  of  the  form  is  to  organize  and  display  database  information  in  a  manner  that  is 
easily  understandable  and  recognizable  to  the  user. 

Although  not  mentioned  by  Rumbaugh  and  others  in  their  modeling  technique,  a 
state  transition  table  provides  a  simple  way  of  summarizing  data  provided  in  state 
diagrams.  It  also  allows  personnel  responsible  for  the  final  analysis  models  and  design  to 
check  if  all  entrance  and  exit  criteria  between  states  have  been  satisfied,  as  well  as 
checking  possible  error  conditions.  Consider  the  Idle  and  In  Use  states  from  Figures  3.18 
and  3.19.  When  the  event  UserLogin  occurs  the  parameter  name  is  passed  to  the  next 
state  InUse.  The  Process  Login  state  (first  substate  of  InUse)  then  becomes  the  current 
state  at  which  time  one  of  four  events  could  occur.  The  login  could  be  invalid,  in  which 
case  the  control  is  passed  back  to  the  Idle  state,  or  one  of  three  types  of  LoginValid 
events  could  be  triggered  depending  upon  the  user  type  guard  condition.  A  partial  state 
transition  table  (Tabled.  1)  is  shown  below  to  coincide  with  the  state  diagrams  just 
discussed.  The  complete  set  of  state  diagrams  and  state  transition  tables  is  provided  in 
Appendix  A. 
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Table  3.1  Partial  state  transition  table  for  Application 


Current  State 

Event 

Parameters 

Guard 

Next  State 

Action 

Idle 

UserLogin 

name 

Process  Login 

Process  Login 

Process  Login 

Process  Login 

Process  Lo?in 

LoginValid 

LoginValid 

LoginValid 

Logininvalid 

ADMIN 

FACULTY 

STUDENT 

Display  Admin  Menu 

Display  Faculty  Menu 
Display  Student  Menu 

Idle 

“Login  Denied” 

Additional  substates  for  the  Present  Options  Menu  and  Process  Selection  substates 
are  presented  as  part  of  the  Data  Dictionary.  States  not  considered  in  either  the  faculty  or 
administrative  scenarios  are  essential  to  the  proper  execution  of  a  STARS  application. 
These  states  have  been  combined  with  Figure  3.21  resulting  in  a  final  state  diagram  for  the 
Process  Selection  state  and  complete  state  transition  table  shown  in  Appendix  A. 

Verify  Consistency.  Now  that  the  state  diagrams  are  complete  we 
can  check  for  consistency  and  completeness  at  the  system  level  by  following  events 
through  the  state  diagrams.  There  should  be  paths  fi’om  initialization  (Start Application)  to 
the  termination  of  the  state  diagram  (EXIT).  Events  should  have  both  a  sender  and 
receiver.  Corresponding  events  on  different  state  diagrams  should  be  consistent.  The 
state  transition  tables  aid  the  designer  in  this  verification  by  tracking  events,  parameters, 
guard  conditions,  and  actions  fi’om  one  state  to  another  [12], 

Functional  Model.  The  fimctional  model  diagrams  the  flow  of  data 
among  processes  with  data  flow  diagrams.  The  functional  model  complements  the 
dynamic  model  in  specifying  the  system’s  behavior.  A  functional  model  was  constructed 
by: 

i)  identifying  input  and  output  variables, 

ii)  drawing  data  flow  diagrams  (DFD)  with  fimctional  dependencies, 

iii)  describing  functions. 
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iv)  identifying  constraints,  and 

v)  specifying  optimization  criteria. 

Input  and  Output  Variables.  Input  and  output  variables  are 

■'St 

parameters  of  events  between  the  system  and  the  outside  world.  Figure  3.22  shows  the 
input  and  output  variables  for  the  STARS  application.  Since  all  interactions  between 
STARS  and  the  outside  world  pass  through  the  application,  all  input  and  output  values  are 
parameters  of  application  events.  Input  events  that  only  affect  the  flow  of  control,  such  as 
Display,  Print,  Abort,  or  Commit,  do  not  supply  input  values. 


messages 

printed  data  ^  ^ 
menu  displays  ' 


USER 

^  * 

APPLICATION 

V 

username  \ 
password  '  ^ 
select  menu  options  ^ 
enter  data 


Figure  3.22  Input  and  output  values  for  application 


Data  Flow  Diagrams  (DFD).  Data  flow  diagrams  show  how  each 
output  value  is  computed  from  input  values.  The  DFDs  that  follow  were  constructed  in 
layers.  Figure  3.23  shows  the  top-level  (level  0)  DFD  for  the  STARS  application.  User 
represents  an  external  object  that  supplies  and  consumes  input  and  output  values, 
respectively.  Data  flows  are  represented  by  the  labeled  arrows,  data  stores  by  the 
‘sandwiched’  labels,  and  processes  by  labeled  ovals.  From  this  top-level  diagram  each 
non-trivial  process  may  be  expanded  recursively  into  lower  level  DFDs  until  all  processes 
are  trivial.  For  example,  the  perform  action  process  from  Figure  3.23  is  expanded  into 
three  processes,  validate  user  login,  offer  menu  options,  and  handle  selection,  as 
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exhibited  in  Figure  3.24.  This  level  1  DFD  in  turn  is  expanded  into  three  level  2  DFDs. 
The  first  process,  validate  user  login  is  shown  in  Figure  3.25.  The  remaining  DFDs  are 
contained  in  the  Data  Dictionary. 


Figure  3.23  STARS  Application  Level  0  DFD 


Figure  3.24  Perform  Action  Level  1  DFD 


DATABASE 


Figure  3.25  Validate  User  Login  Level  2  DFD 
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operations.  Higher-level  processes  may  also  be  considered  operations,  although 
optimization  may  allow  for  a  varying  implementation.  The  specifications  for  non-trivial 
operations  are  contained  in  the  Data  Dictionary.  Non-trivial  operations  can  be  divided 
into  three  categories:  queries,  actions,  and  activities.  The  fiinction  description  for  the 
validate  user  login  process  is  outlined  in  Figure  3.26.  Note  the  process  relies  on  two 
variables,  name  and  password  as  input,  and  provides  messages  and  a  user  type  as  output. 

Validate  User  Login  (name,  password)  user  type,  messages 
If  the  name  entered  matches  a  valid  user  then 
allow  password  verification 
If  the  password  entered  matches  a  valid  password  then 
send  a  message  notifying  user  of  valid  access 
If  name  or  password  entered  does  not  match  valid  user  then 
_ send  message  notifying  user  of  denied  access _ 

Figure  3.26  Function  description  for  Validate  User  Login  process 

Constraints.  Constraints  show  relationships  between  two  objects 
at  the  same  time  or  between  different  values  of  the  same  object  at  different  times. 
Constraints  may  appear  in  all  three  analysis  models.  Preconditions  on  functions  are 
constraints  input  values  must  satisfy,  and  post  conditions  are  constraints  that  output  values 
are  guaranteed  to  hold.  The  conditions  under  which  constraints  must  hold  are  stated  in 
brackets. 

'Optimization  Criteria.  Potential  optimizing  criteria  for  a  database 
system  are  to  minimize  the  time  objects  are  locked,  or  if  needed  the  entire  database  is 
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locked.  Another  criteria  is  to  maximize  the  use  of  functions  and  procedures  by  taking 
advantage  of  superclass-subclass  relationships,  and  multiple  inheritance. 

Final  Analysis.  When  the  analysis  is  complete,  the  models  should  reflect 
the  requirements  expressed  in  the  problem  statement  and  those  requested  by  the  user.  In 
an  effort  to  provide  a  good  final  design  the  analysis  process  is  wrapped  up  (but  may 
continue  through  the  software’s  life-cycle)  by  adding  operations  to  the  object  model  and 
verifying  the  models  meet  requirements. 

Add  Functional  Model  Operations.  The  defining  of  operations 
for  objects  is  an  open-ended  process,  but  it  is  usefiil  to  try  to  identify  potentially  useful 
operations  and  summarize  them  on  the  object  model.  The  operations  are  obtained  from 
many  of  the  diagrams  and  models  we  have  already  constructed.  For  example,  the  object 
model  implies  reading  and  writing  attribute  values  and  association  links  (such  as 
get  attribute  and  set  attribute).  Events  sent  to  objects  correspond  to  an  operation  on  an 
object.  Actions  and  activities  in  the  state  diagram  may  be  fijnctions  (such  as  Process 
Login  or  Verify  Selection).  Each  function  in  the  DFD  corresponds  to  an  operation  on  an 
object  or  several  objects. 

After  organizing  all  the  operations  on  the  object  model,  examine  it  for  duplicate 
operations  or  variations  of  a  single  operation.  Sometimes  an  object  class  will  suggest 
operations  that  should  be  included  for  possible  use  in  other  problems  (i.e.  initialization  or 
finalization).  These  should  be  added.  The  final  object  diagrams  with  operations  are 
shown  in  Appendix  A. 

Compare  Models  with  Problem  Statement.  One  way  to  judge  a 
design  for  soundness  is  to  compare  the  models  to  the  problem  statement.  The  models 
should  capture  most  requirements,  and  requirements  involved  with  performance 
constraints  should  clearly  be  stated  in  the  optimization  criteria. 


3-23 


Develop  More  Detailed  Scenarios.  Another  way  of  verifying 
correctness  is  by  going  back  to  the  user,  or  consulting  with  an  application  domain  expert. 
These  activities  amount  to  testing  the  domain  limits  by  developing  more  detailed  scenarios 
and  verify  that  the  models  handle  varying  static,  dynamic,  and  functional  conditions. 
Additional  scenarios  are  provided  in  Appendix  A. 

System  Design.  In  Object-Oriented  Modeling  and  Design,  Rumbaugh  and 
associates  present  an  ideal  life  cycle  for  a  database  application  as  [19:367]: 

1 .  Design  the  application. 

2.  Devise  an  architecture  for  coupling  the  application  to  a  database. 

3.  Select  a  specific  DBMS  platform. 

4.  Design  the  database.  Write  DBMS  code  to  set  up  the  proper  database 
structures. 

5.  Write  programming  language  code  to  provide  user  interface,  validate  data,  and 
perform  computations. 

6.  Populate  the  database  with  information. 

7.  Run  the  application. 

For  the  purpose  of  this  research  the  first  four  of  the  seven  stages  of  the 
application's  life-cycle  are  of  interest.  Since  we  are  not  implementing  executable  code  the 
last  three  stages  are  of  little  interest  to  us  and  are  presented  to  provide  for  a  complete  life- 
cycle  process.  The  first  of  the  seven  stages  is  captured  as  a  result  of  OMT  analysis  effort  - 
-  the  three  models  forming  the  fi-amework  of  the  design.  The  architecture  chosen  to 
couple  the  application  to  a  database  is  transparent,  as  will  be  shown  in  the  upcoming 
section  on  mapping  object  models  to  an  OODBMS.  This  is  contrasted  with  the  more 
traditional  approach  of  the  table  architecture  supported  by  relational  databases.  The 
DBMS  platform  selected  is  one  proposed  as  an  ODBMS  standard  in  R.G.G.  Cattell  and 
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others'  book,  The  Object  Database  Standard  [5],  Finally,  designing  the  database  is 
discussed  in  the  following  subsections  and  the  Implementation  chapter. 

When  using  an  existing  database  management  system  the  main  concern  is  to 
construct  an  object  model  and  decide  upon  the  transactions  that  must  be  considered 
atomic  by  the  system.  Steps  in  designing  a  transaction  manager  are  [  1 9 : 2 1 6] : 

1 .  Map  the  object  model  directly  into  the  database. 

2.  Determine  which  resources  cannot  be  shared  (units  of  concurrency). 

3.  Determine  the  set  of  resources  that  must  be  accessed  together  during  a 
transaction  (unit  of  transaction). 

4.  Design  concurrency  control  for  transactions. 

The  steps  presented  for  designing  a  transaction  manager  deal  with  making  sure 
that  the  integrity  and  consistency  of  stored  data  is  maintained.  This  transaction 
management  is  atomic,  which  means  that  transactions  either  happen  as  a  whole  or  do  not 
happen.  This  research  does  not  discuss  the  implementation  of  transaction  control, 
although  it  is  discussed  in  ODMG-93  and  would  be  imperative  to  operating  any 
information  system  that  has  multiple  users  and  is  expected  to  share  data.  The  first  step  for 
the  transaction  manager  is  to  map  the  object  model  into  the  DBMS.  This  is  discussed  in 
the  next  subsection.  The  remaining  steps  are  not  discussed  and  are  provided  to  keep  a 
complete  representation  of  the  process  to  be  followed. 

Object  Model  Mapped  to  Database.  A  relational  database  logically 
appears  as  a  collection  of  tables.  In  the  design  of  a  relational  database  application  it  is 
necessary  for  the  designer  to  map  an  object  model  (or  entity-relationship  diagram)  into  a 
table  model.  The  programmer  then  takes  this  table  model  and  implements  it  in  a  relational 
database  language.  SQL  is  used  for  the  examples  that  follow  since  it  the  most  widely  used 
relational  database  language. 
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In  contrast  to  this  three-level  approach  of  mapping  design  to  implementation, 
object-oriented  databases  offer  the  potential  of  doing  away  with  the  table  level  of  mapping 
and  allowing  the  designer/implementor  to  map  directly  from  the  object  model  to 
implementation.  Figure  3.27  summarizes  this  concept.  The  impact  of  this  change  will  aid 
both  developers  and  maintainers  because  software  will  be  more  tightly  coupled  to  design 
and  maintenance  documentation. 


Object 

Model 


I 


Table 

Model 


f  ^ 

L 

Implementation 

Figure  3.27  Comparison  of  Database  Management  System  Architectures 

In  the  book  Object-Oriented  Design  [9:82-83],  Coad  and  Yourdon  describe  this 
mapping  from  the  object  model  to  implementation  as  "a  seamless  view  of  objects; 
translating  between  storage  data  structures  and  program  data  structures  is  no  longer 
needed"  because  object-oriented  DBMS  will  take  care  of  saving  and  restoring  the  objects. 
Designers  and  programmers  will  rely  upon  the  ability  of  object-oriented  DBMS  to  handle 
this  type  of  activity  and  their  work  will  involve  mapping  the  object  model  into  a  feasible 
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design.  Mapping  basic  modeling  concepts  to  an  implementation  is  relatively 
straightforward  and  easy  to  visualize.  An  example  of  mapping  an  object  class  to 
implementation  is  discussed  for  the  Person  object  class  below.  Additional  comparisons 
(i.e.  associations,  inheritance,  multiple  inheritance)  are  contained  in  Appendix  A. 

Advanced  modeling  concepts  are  more  difficult  to  map  to  object-oriented 
databases.  The  two  advanced  modeling  concept  examples  presented  are  for  a  ternary 
association  and  an  association  with  link  attributes.  The  following  sections  illustrate  the 
differences  experienced  in  mapping  an  object  model  into  a  relational  database  versus  an 
object  oriented  database.  In  the  examples,  SQL  and  OQL  (proposed  in  R.G.G.  Cattell's 
book  The  Object  Database  Standard:  ODMG-93  [5])  are  used  to  show  a  pseudo-code 
implementation. 

Mapping  Object  Classes.  The  object  class  is  the  basic  building 
block  of  object  oriented  design.  Figure  3.28  illustrates  the  steps  necessary  to  implement 
the  Person  object  class  in  a  relational  database.  First,  the  class  Person  is  mapped  to  the 
Person  table  where  a  unique  key  is  assigned  for  handling  activities.  Attributes  of  the  class 
are  assigned  fields  with  data  types  defined  by  the  domain,  and  required  input  constraints 
are  defined  by  the  predefined  "Null'  constant.  From  this  table  the  person  class  is 
implemented  in  a  relational  database  with  the  SQL  code  shown. 
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Object 

Model 

t 

Table 

Model 

( 


Person _ 

Last  Name 
First  Name 
Middle  Initial 
SSAN 


Person  Ta 

jle 

Attribute  name 

Nulls 

Domain 

person-ID 

N 

ID 

last-name 

N 

name 

middle-initial 

Y 

char 

first-name 

Y 

name 

SSAN 

N 

SSAN 

Candidate  Key:  (person-ED) 

Primary  Key:  (person-ID) 

Frequently  accessed:  (person-ID)  (SSAN)  (last-name) 


CREATE  TABLE  Person 


(  person-BD 

ID 

not  null. 

SQL 

last-name 

char(30) 

not  null. 

Code 

middle-initial 

char 

> 

first-name 

char(30) 

J 

SSAN 

integer(9) 

not  null. 

PRIMARY  KEY  (person-ED)  ); 

CREATE  SECONDARY  INDEX  Person-index-name 


ON  Person  (last-name) 

CREATE  SECONDARY  INDEX  Person-index-name 


ON  Person(SSAN) 


Figure  3.28  Mapping  object  class  to  relational  database 

In  comparison  to  the  relational  SQL  implementation  required  to  prepare  the 
database  for  data  input,  the  object-oriented  database  is  more  direct  (object  model  to 
implementation)  and  easier  to  understand  (no  table  concepts  to  interpret),  as  shown  in 
Figure  3.29.  The  Person  Object  Identifiers  (OID)  are  assigned  with  the  key  declaration, 
and  attributes  not  assigned  default  values  require  input  upon  creation.  The  keys  in  Figure 
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3.29  are  SSAN  and  last  name  which  allow  an  instance  of  the  Person  object  to  be  uniquely 
identified.  The  key  designator  also  requires  that  the  attributes  listed  be  provided  values 
upon  an  object  instance  creation,  just  as  the  'not  null'  did  in  the  relational  example.  In 
contrast  to  the  relational  depiction  in  Figure  3.28  where  likely  access  paths  are  identified 
through  the  creation  of  indexes  access  through  objects  will  take  place  through  the 
associations  modeled  in  the  OMT  object  diagrams.  The  relationship  identifier  recipient  is 
shown  with  an  inverse  identifier  of  awarded  Jo  shows  a  likely  access  path  between  the 
two  objects  Person  and  Award. 


Object 

Model 


Person _ 

Last  Name 
First  Name 
Middle  Initial 
SSAN 


EVTERFACE  Person 
(  EXTENT  persons 

KEYS  SSAN,  last_name ) 

{ 

ATTRIBUTE  String  Iast_name; 

OQL  ATTRIBUTE  String  first_name; 

ATTRIBUTE  Character  middle_initial; 
ATTRIBUTE  Integer(9)  SSAN; 
RELATIONSHIP  Set<Award>  recipient 

INVERSE  Award:  :awarded_to; } 


Note:  Attributes  may  be  assigned  default  values. 

Figure  3.29  Mapping  object  class  to  object-oriented  database 
Mapping  Ternary  Associations.  Mapping  ternary  associations  into  a  relational 
database  is  handled  by  creating  a  table  of  table  keys  for  the  ternary  association  and  any 
additional  fields  for  link  attributes.  An  example  of  this  mapping  is  shown  in  Figure  3.30. 
A  primary  key  is  created  on  the  tuple  (student-ID,  quarter-DD,  section-DD).  Additional 
access  to  the  tables  is  provided  through  each  foreign  key  on  student,  quarter,  or  section. 
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Object 

Model 


Table 

Model 


SQL 

Code 


QUARTER 


STUDENT  k 


enrolled  in 


1 

’contains 

offered  j 

SECTION 

- « 

Student-Quarter-Section 

candidate  k;ey(  student-ID,  quarter-DD,  section-ID  ) 


Student,  Quarter,  and  Section  Tables  created  similar  to  Figure  3.28 


Student-Quarter-Section  Table 


Attribute  name 

Nulls 

Domain 

student-ID 

N 

ID 

quarter-ID 

N 

ID 

section-ID 

N 

ID 

Candidate  key;  (student-ID,  quarter-ID,  section-ID) 
Primary  key:  (student-ID,  quarter-ID,  section-ID) 
Frequently  accessed:  (student-ID)(quarter-ID)(section-ID) 


CREATE  TABLE  Student 

(  student-ID  ED  not  null, 

attributes, 

PRIMARY  KEY  (student-ID)  ); 

Similar  CREATE  TABLES  for  Quarter  and  Section 

CREATE  TABLE  Student-Quarter-Section-temary 
(  student-ID  ID  not  null, 

quarter-ID  ID  not  null, 

section-ID  ID  not  null, 

PRIMARY  KEY  (student-ID,  quarter-ID,  section-ID) 
FOREIGN  KEY  (student-ID)  REFERENCES  Student, 
FOREIGN  KEY  (quarter-ID)  REFERENCES  Quarter, 
FOREIGN  KEY  (section-ID)  REFERENCES  Section  ); 

Figure  3.30  Mapping  ternary  association  to  relational  database 
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In  the  ODMG-93  standard  [5]  the  authors  specifically  define  relationships  as  types 
between  object  types.  The  ODMG-93  object  model  can  support  only  binary  relationships 
(no  «-ary  relationships).  An  object  model  allowing  only  binary  relationships  forces 
designers  to  break  «-ary  relationships  into  some  binary  equivalent.  As  pointed  out  in 
Object  Modeling  and  Design,  the  majority  of  «-ary  relationships  can  successfully  be 
modeled  as  binary  relationships[19:159]. 


QUARTER 


registered_for 


has  offers 


STUDENT 


takes 


oftered_in 

SECTION 


Figure  3.31  Ternary  association  with  binary  relationships 


Figure  3.31  demonstrates  one  approach  to  modeling  the  ternary  association  with 
binary  relationships.  The  difficulty  in  implementing  this  approach  is  that  the  enforcement 
of  rules  managing  the  access  of  objects  via  relationships  is  left  to  the  implementor.  Take 
as  an  example,  a  known  student  OID,  and  a  requested  output  of  all  sections  taken  in  all 
quarters  for  the  given  student.  This  output  requires  the  traversal  of  the  many-to-many 
relationship  between  Student  and  Quarter  to  obtain  the  set  of  quarters  for  which  the 
student  is  enrolled.  Each  quarter  results  in  another  many-to-many  relationship  between 
Quarter  and  Section.  Traversing  this  relationship  for  each  quarter  in  the  set  produces  the 
set  of  course  sections  offered  in  those  quarters.  The  implementor  would  then  use  the 
many-to-many  Student-Section  relationship  to  obtain  the  set  of  course  sections  for  which 
the  student  is  taking  courses.  This  set  would  then  need  to  be  logically  intersected  with  the 
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previous  set  of  course  sections  to  obtain  the  common  subset  of  courses.  This  subset  could 
then  be  further  divided  into  smaller  subsets  by  using  the  offers  relationship  and  obtaining 
the  sets  of  sections  taken  by  the  student  for  each  quarter  in  which  they  were  enrolled. 

Implementing  this  object  model  requires  each  of  the  object  classes  Student, 

Quarter,  and  Section  to  define  two  binary  relationships;  one  each  to  the  other  two  object 
classes.  The  corresponding  Object  Data  Language  for  the  Section  object  is  shown  in 
Figure  3.32.  The  operations  defined  by  the  user  would  need  to  take  into  account  both  the 
offered Jn  and  enrolls  relationships  as  well  as  the  existence  of  any  link  attributes 
embedded  in  one  of  the  other  objects. 

interface  Section 
(  extent  sections ) 

{ 

attribute  Character  symbol; 
relationship  Set<Quarter>  oflfered  in 
inverse  Quarter;: offers; 
relationship  Set<Student>  enrolls 
inverse  Student  ::enrolled_in; 
operations 

}; 

Figure  3.32  ODL  for  ternary  association  modeled  with  binary  relationships 

Another  approach  to  modeling  the  ternary  association  is  to  abstract  the 
relationship  as  an  object  consisting  of  inverse  pointers  to  the  objects  forming  the 
association.  Figure  3.33  shows  this  modeling  approach  with  each  object  class,  Student, 
Quarter,  and  Section  having  a  one-to-many  relationship  with  the  object  Registration,  thus 
forming  the  ternary  relationship  among  the  three  objects.  Figure  3.34  presents  the 
corresponding  Object  Data  Language  for  the  Section  and  Registration  objects  from  Figure 
3.33.  As  shown  in  the  figures,  the  relationship  object  Registration  will  contain  the 
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operations  permissible  for  the  ternary  relationship  among  the  objects  Student,  Quarter, 
and  Section. 


QUARTER 


contains 


enrollecl_in 

offered 

STUDENT 

REGISTRATION 

SECTION 

Figure  3.33  Abstracting  the  ternary  relationship  as  an  object 


interface  Section 
(  extent  sections ) 

{ 

attribute  Character  symbol; 

relationship  Set<Registration>  offeredjn  inverse  Registration;; offers; 
operations 

) 

Similar  implementation  for  Student  and  Section 

interface  Registration 
(  extent  registration ) 

{ 

link  attributes  as  required 

relationship  Set<Section>  offers  inverse  Section;  ;offered_in; 
relationship  Set<Student>  enrolled  inverse  Student  ;;enrolled_in; 
relationship  Set<Quarter>  contains  inverse  Quarter;  ;contained_in 
operations 

} 


Figure  3.34  ODL  for  abstract  ternary  relationship 


Considering  this  example  is  one  of  six  scenarios  for  acquiring  data  from  this 
ternary  association  it  is  easy  to  see  why  making  provisions  for  ternary  associations  within 
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an  OODBMS  would  be  a  useful  and  powerful  addition.  An  additional  object  modeling 
constraint  arises  when  a  link  attribute  to  the  ternary  association  is  considered.  The  link 
attribute  modeling  notation  causes  similar  problems  as  previously  discussed  because  the 
embedding  of  link  attributes  to  one  of  the  three  classes  requires  the  implementor  to 
provide  access  to  the  link  attributes  from  any  of  the  other  object  classes. 

Rumbaugh  and  associates  also  note  the  fact  that  certain  ternary  relationships 
cannot  be  successfully  broken  into  binary  relationships  without  losing  some  information 
captured  in  the  model  [19: 159].  The  Student-Quarter-Section  relationship  is  one  such 
example.  Considering  this  observation  and  the  added  complexity  forced  upon  the 
database  user  in  trying  to  manage  ternary  relationships,  a  more  effective  solution  would  be 
to  extend  the  ODMG-93  standard  [5:59-64]  to  allow  ternary  associations  and  manage  the 
traversals  among  the  three  objects  and  any  link  attributes. 

The  proposed  Backus  Naur  Form  (BNF)  for  an  «-ary  relationship  specification 
follows: 


<temary_rel_declaration> 


<relationships_list> 

<target_of_path> 

<identifier_list> 


<attribute_list> 


ternaryrelationship 

<relationships_list> 

[traverse  <identifier_list>] 

[{order_by  <attribute_list>}] 

<target_ofjpath>  <identifier> 

I  <target_of_path>  <identifier>,  <relationships_list> 
<identifier> 

I  <relationship_collection_type>«identifier» 
<identifier> 

1  <identifier>  ::  <identifier> 

1  <identifier>  : :  <identifier>,  <identifier_list> 
<scoped_name>,  <attribute_list> 


This  extension  allows  the  ternary  relationship  Student-Quarter-Section  to  be  defined  and 
added  to  the  objects'  specifications.  As  an  example.  Figure  3.35  shows  the  ternary 
association  with  the  proposed  BNF  specification  applied  to  the  Section  type's  interface 
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specification.  Similar  specifications  would  be  created  for  the  Student  and  Quarter  object 
classes. 


Object 

Model 


♦ 


OQL 


QUARTER 


STUDENT 


W:ontains 

offered 

o — 


registration 


SECTION 


interface  Section 
(  extent  sections 

keys  symbol ):  persistent 

{ 

attribute  String  symbol 

ternary  relationship  Set<Students>  class  roster, 
Set<Quarters>  offeredjn 
traverse  Set<Quarters>  : :  schedule_of_courses 
traverse  Set<Students>  ::  registered_for  }; 


Figure  3.35  Mapping  ternary  association  to  object-oriented  database 


This  approach  to  capturing  ternary  associations  follows  the  guidelines  set  forth  in  ODMG- 
93  for  relationships  (except  for  no  «-ary  relationships)  [4:23,45,54]: 

•  relationship  types  are  defined  between  (mutable)  object  types 

•  traversal  paths  are  defined  between  (mutable)  object  types 

•  traversal  names  are  defined  for  each  direction  of  traversal 

•  traversal  names  are  declared  within  the  interface  definitions  of  the  object  type 

•  relationships  maintain  referential  integrity 

•  relationship  instances  do  not  have  OIDs 

This  proposed  extension  would  group  an  objects'  relationships  together  so  that  operations 
affecting  the  Student-Quarter-Section  ternary  association  could  be  handled  by  the  ODMS. 
However,  it  does  not  solve  the  problem  of  implementing  a  ternary  association  with  link 
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attributes.  Since  relationships  do  not  have  OIDs,  link  attributes  cannot  be  stored  in  a 
relationship  itself.  The  designer  or  implementor  is  thus  forced  to  implement  link  attributes 
as  part  of  one  of  the  objects  in  the  relationships. 

Mapping  associations  with  link  attributes.  A  second  proposed 
extension  to  ODMG-93  would  relax  three  guidelines  of  the  standard  for  implementing  a 
relationship  (besides  no  «-ary  relationships)  and  allow  for  link  attributes  on  all 
relationships.  The  guidelines  that  would  be  broken  are: 

•  traversal  paths  are  defined  between  (mutable)  object  types 

•  traversal  names  are  defined  for  each  direction  of  traversal,  and 

•  relationship  instances  do  not  have  OIDs 

Conceptually,  what  this  second  approach  proposes  is  to  treat  relationships  as  an  object,  in 
which  object  pointers  involved  in  the  relationship  are  stored  along  with  link  attributes. 
Permissible  operations  on  the  association  or  link  attributes  would  reside  with  the 
relationship  object.  The  BNF  for  this  second  approach  would  be: 

<link_relationship_declaration>  ::=  link_reIationship  <relationship_identifier> 

As  an  example,  the  Student-Quarter-Section  ternary  relationship  would  now  be 
implemented  as  shown  in  Figure  3.36.  This  approach  to  implementing  a  ternary 
relationship  allows  the  implementor  to  associate  link  attributes  with  the  relationship  in 
which  they  logically  occur. 
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Object 

Model 


interface  Section 
(  extent  sections 

keys  symbol ):  persistent 

{ 

attribute  String  symbol 

link  relationship  Registration  }; 

Similar  interface  specifications  for  Quarter  and  Student 

interface  Registration 
(  keys  student-OID 

quarter  OED 

section-OID ):  persistent 

relationship  Set  <Students> 
relationship  Set  <Quarters> 
relationship  Set  <Sections> 
attribute  Enumeration  type 
attribute  Enumeration  status 
attribute  Enumeration  grade  }; 

Figure  3.36  Mapping  association  with  link  attribute  to  object  database 


Summary.  This  chapter  has  presented  the  four  OMT  steps  used  to  build  the 
three  analysis  models  for  an  AFIT  information  system.  A  problem  statement  was 
developed  by  reading  software  support  documentation,  and  consulting  with  present 
AFITSIS  users  and  maintainers.  An  object  model  was  constructed  from  the  problem 
statement  and  problem  domain.  Dynamic  and  functional  models  were  constructed  from 
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system  scenarios.  Object  model  updating  continued  as  data  was  viewed  from  different 
perspectives,  or  changes  to  object  relationships  were  identified.  As  noted  in  the  section  on 
Mapping  Ternary  Associations  the  two  approaches  that  were  proposed  to  aid  in  the 
implementation  of  ternary  and  link  attribute  modeling  concepts  in  object-oriented  database 
systems  still  result  in  the  loss  of  ternary  modeling  information.  The  proposed  approaches 
called  for  expanding  the  ODMG-93  standard  to  make  provisions  for  both  of  the  modeling 
concepts  freeing  developers  and  designers  from  're-inventing'  code  to  manage  such  data. 
The  object  database  management  system  standard,  ODMG-93,  specifically  prohibits  «-ary 
relationships  and  ignores  the  existence  of  link  attributes.  Therefore,  in  order  to  map  the 
modeling  of  such  associations  into  the  ODBMS  defined  by  the  ODMG-93  standard  the 
design  presented  calls  for  abstracting  the  relationship  into  an  object  and  enforcing  ternary 
rules  through  the  operations  provided  by  the  relationship  object. 

The  next  chapter  discusses  the  implementation  issues  which  must  be  resolved  in 
order  to  implement  the  AFITSIS  revision.  Emphasis  is  on  the  data  manipulation  language 
required  to  implement  object  models  in  both  relational  database  management  systems  and 
object-oriented  database  management  systems.  The  three  database  languages  compared 
are  the  relational  SQL,  the  SQL-like  OQL,  and  a  'fiiture'  OQL. 
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IV.  Implementation  Issues 


Introduction.  A  prototype  of  the  student  tracking  and  registration  system  was 
not  implemented  on  the  ODMG-93  ODBMS  standards  because  such  systems  are  still 
under  development.  This  paper  analyzes  and  designs  an  information  system  to  the 
proposed  standards  to  study  how  object-oriented  analysis  and  design  fit  with  the 
anticipated  OODBMS  interfaces.  An  advertised  advantage  of  object-oriented  database 
management  systems  is  the  ability  to  create  different  views  of  persistent  data.  This  chapter 
presents  views  from  the  student  tracking  and  registration  system,  and  the  database 
language  (SQL  and  OQL)  pseudo  code  necessary  to  implement  those  views.  The  first 
view  considered  is  that  of  a  student's  class  schedule.  The  second  example  expands  upon 
the  student  class  schedule  object  model  by  adding  a  relationship  to  obtain  more 
information  from  the  same  objects.  Additional  models  are  contained  in  Appendix  A. 

Student  Class  Schedule.  A  student  class  schedule  represents  perhaps 
the  most  often  used  form  from  a  school's  database.  The  schedule  represents  the  current 
student's  schedule  information  with  respect  to  the  quarter  enrolled,  degree  and  program 
being  pursued,  and  classes  being  taken.  Figure  4. 1  presents  the  general  outline  of  a  blank 
student  class  schedule.  Figure  4.2  is  the  class  schedule  object  model  constructed  to 
support  the  class  schedule  in  Figure  4. 1 .  For  the  sake  of  simplicity  the  object  model 
presented  lists  only  those  attributes  associated  with  the  student  class  schedule. 
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Student  Name 

Box  Number 

Year  Quarter:.  Dates  Inclusive 

GRD 

START  END 

COURSE  TITLE  HRS  TYP 

DAYS  TIME  TIME  BLDG  ROOM  INSTRUCTOR 

SCHOOL: 

DEGREE: 

CLASS: 

PROGRAM: 

Figure  4.1  Student  class  schedule 


Figure  4.2  Student  class  schedule  object  model 
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As  described  in  Chapter  III  the  object  model  shown  in  Figure  4.2  can  be  designed 


for  either  a  relational  or  object  database  management  system.  The  examples  that  follow 
assume  that  the  relational  tables  and  objects  have  been  created  and  databases  are 
populated  with  valid  data.  In  the  SQL  and  OQL  pseudo-code  presented  the  bold  faced 
text  represent  reserved  words.  As  part  of  the  analysis  and  design  it  is  necessary  to  decide 
on  what  information  is  required  from  the  database  and  to  construct  the  algorithms 
necessary  to  get  that  data.  The  following  algorithm  constructs  a  student  class  schedule 
from  the  object  diagram;  the  algorithm  assumes  input  of  the  student's  social  security 
account  number  and  the  quarter  of  interest  (asterisks  in  the  left  margin  identify  the  portion 
of  the  algorithm  discussed  in  the  next  subsection): 


Build  schedule  on  student's  identification  and  quarter. 

Obtain  Instance  of  Student  and  Quarter. 

**  Output  Student's  First  Name,  Middle  Initial,  Last  Name,  and  Box  Number. 

Output  Year,  Term,  Start  Date  and  End  Date  for  instance  of  quarter. 

**  (With  student  id  and  quarter)  Traverse  Student-Section-Quarter  enrolledjn  ternary  association 
to  get  instances  of  sections  student  is  enrolled  in. 

**  For  each  section  instance: 

**  Output  Section  Symbol. 

Output  enrolledjn  ternary  association  linked  attribute  Grade  Type. 

Traverse  Section-Course  belongs  to  association  to  get  instance  of  Course. 

Output  Coiuse's  Number,  Title,  and  Credit  Hours. 

For  each  course  instance: 

Traverse  Course-Department  offers  association  to  obtain  instance  of  Department. 
Output  Department  symbol. 

Traverse  Section-Faculty  taught  by  association  to  obtain  instance  of  Faculty. 

Output  Faculty's  Last  Name. 

Traverse  Section-Room  meets  in  association  to  obtain  instance  of  Room. 

Output  Building  Number. 

Output  meetsjn  linked  attributes  Room,  Days,  Start  Time,  and  End  Time. 

Traverse  Student-Degree  pursues  association  to  obtain  instance(s)  of  Degree. 

Output  Degree  Title  (Degree)  and  Type  (Class). 

Traverse  Student-Department  assigned  Jo  association  to  obtain  instance  of  Department. 

Output  assignedjo  linked  attribute  Program. 

Traverse  Department-School  part_of  aggregation  to  obtain  instance  of  School. 

Output  School. 


SQL  versus  OQL  Comparison.  The  discussion  of  SQL  versus 
OQL  considers  the  retrieval  of  a  student's  name  and  course  information,  shown  by 
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asterisks  along  the  left  margin  of  the  algorithm  above.  Examples  of  the  full  SQL  and  full 
OQL  implementations  of  the  complete  algorithm  creating  a  student  schedule  is 
documented  in  Appendix  A  along  with  additional  views  of  the  information  system.  For 
both  implementations  the  user  inputs  are  assumed  to  be  InputSSAN  and  InputTerm. 
Assume  the  following  relational  tables  exist  (fields  not  associated  with  this  example  have 
been  left  out  for  simplicity): 

Course_Taught_By(  Course  TaughtOOTerm  Code,  Course  Prefix  Code,  Course  Number, 

Course  Section,  Faculty_SSAN ) 

Grade_History(  Course  Prefix  Code,  Course  Number,  Course  Section,  ScheduleOOTerm  Code, 
SSAN,  Credit  Hours,  Grade  Type  Code ) 

Schedulef  Course  Prefix  Code,  Course  Number,  Course  Section,  Course  Start  Time, 
Course_End_Time,  Course  Title,  Day  Code,  ScheduleOOBuilding  Code, 

ScheduleOORoom  Code,  ScheduleOOTerm  Code ) 

Person(  SSAN,  First  Name,  Last  Name,  Middle  lnitial ) 

Resident_Student(  SSAN,  Classrfication  Code,  AFIT  Degree  Code,  Program  Code,  Box  Number, 
Selected_Type_Code ) 

Terms(  Term_Code,  Term ) 

Term_Date(  Term_Code,  Term_Start_Date,  Term_End_Date ) 


From  the  Person  and  Resident  Student  relational  tables  a  view  is  created, 

View  Person  Resident,  to  simplify  the  amount  of  data  being  handled  by  the  system.  The 
View  Per  son  Resident  table  is  then  joined  with  tables  Terms  and  Term  Date  so  a 
selection  on  the  input  variables  InputSSAN  and  InputTerm  will  result  in  the  student's  name, 
box  number,  and  term  information.  Next,  the  Grade  History  and  Schedule  tables  are 
joined  and  a  set  of  courses  extracted  on  InputSSAN  and  InputTerm.  The  courses  of  this 
set  are  those  in  which  the  student  is  enrolled  for  the  given  term.  Joining  the  Person  and 
Course  Taught  By  tables  and  using  the  courses'  identifiers,  InputSSAN,  and  InputTerm 
the  instructor  for  each  course  may  be  obtained.  The  pseudo-code  (with  SQL)  is  shown 
below: 


create  view  View_Person_Resident(  SSAN,  Last  Name,  First_Name,  Middle  lnitial, 
Box  Number )  as 

(select  SSAN,  Last  Name,  First  Name,  Middle_Initial 
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from  Person,  Resident  Student 

where  Person.  SS AN  =  Resident  Student.SSAN ) 

select  First_Name||'  '||Middle_Initial||'  '||Last_Name,  Box_Number,  Term||' :  '||Term_Start_Date||' 
to '  ||Term_End_Date 
into  Name,  Box  Number,  Term  info 

from  View  Person  Resident,  Terms,  Term  Date 
where  View_Person_Resident.SSAN  =  /«pMtS'iS4A 
and  Terms.TermCode  =  InputTerm 
and  TermDate.TermCode  =  InputTerm 

Output(  Name,  Box  Number,  Term  info ) 

select  Grade_History.Course_Prefix_Code,  Grade  History.Course  Number, 

Grade  History.Course  Section,  Course  Title,  Grade  History.Credit  Hours, 
Grade_Type_Code,  NVL(Day_Code,'TBA’),  Course_Start_Time,  Course_End_Time, 
NVL(ScheduleOOBuilding_Code,  'TBA'),  NVL(ScheduleOORoom_Code,  'TBA') 
into  Course  Prefix  Code,  Course  Number,  Course_Section,  Course  Title,  Credit  Hours, 
Grading  Type,  Days,  Start  Time,  End  Time,  Building,  Room 
from  Grade_History,  Schedule 
where  Grade  Histoiy.SSAN  =  /mpm/S'&4A^ 
and  Grade  History.ScheduleOOTerm  Code  =  InputTerm 
and  Schedule.  ScheduleOOTerm_Code  =  InputTerm 
and  Grade_History.Course_Prefix_Code  =  Schedule.Course_Prefix_Code 
and  Grade_History.Course_Number  =  Schedule.  Course_Number 
and  Grade_History.Course_Section  =  Schedule.Course_Section 
Output(  Course_Prefix_Code,  Course_Number,  Course_Section,  Course_Title,  Credit_Hours, 
Grading_Type,  Days,  Start_Time,  End_Time,  Building,  Room ) 

LocalCourseJPrefixjOode  =  Course_Prefix_Number 
LocalCourse_Number  =  Course_Number 
LocalCourseJSection  =  Course_Section 

select  Last_Name 
into  Instructor 

from  Person,  Course_Taught_By 

where  Person.  SSAN  =  Course_Taught_By.Faculty_SSAN 
and  Course_Taught_By.Coiu:se_TaughtOOTerm_Code  =  //7;7Mtrerffj 
and  Course  Taught  By.Course  Prefix  Code  =  LocalCourse  Prefix  Code 
and  Course_Taught_By.Course_Number  =  LocalCourse  Number 
and  Course_Taught_By.Course_Section  =  LocalCourse _Section 
Output(  Instructor ) 


In  a  similar  fashion  queries  were  constructed  on  objects  of  an  object-oriented 
database  system.  As  with  the  relational  example  above  it  is  assumed  that  the  objects  from 
Figure  4.2  have  been  created,  data  is  available,  and  the  user  inputs  are  InputSSAN  and 
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InputTerm.  The  pseudo-code  (using  proposed  ODMG-93  OQL)  to  construct  the  student 
schedule  follows: 

select  distinct  LocalStudent 
from  X  in  Students 
where  x.SSAN  =  InputSSAN 

Output(  LocalStudent.First_Name,  LocalStudent.Middle  lnitial,  LocalStudent.Last  Name, 
LocalStudent.  Box  Number ) 

select  ScheduleClasses 

from  X  in  Student-Registration 
y  in  Quarter.Registration 
where  x.SSAN  =  InputSSAN 
and  y.Term  =  InputTerm.  Term 
and  y.Year  =  InputTerm.  Year 

for  index  in  first(ScheduleClasses) ..  last(ScheduleClasses)  loop 
element(  select  LocalCourse 

from  X  in  ScheduleClasses[index].belongs_to) 
select  LocalDepartment 
from  X  in  Course 
y  in  x.offered_by 
where  x  =  LocalCourse 

Output(  LocalDepartment.  Symbol,  LocalCourse.Number, 

ScheduleClasses[index]. Symbol,  LocalCourse.Title,  LocalCourse.  CreditHours, 
ScheduleClasses[index].Registration.Type ) 

select  LocalBuilding 

from  X  in  ScheduleClasses[index] 
y  in  x.meetsin 
where  x  =  LocalCourse 

Output(  ScheduleClasses[index].Plan.Days,  ScheduleClasses[index].Plan.Start_Time, 
ScheduleClasses[index].Plan.End_Time,  LocalBuilding.Number, 
ScheduleClasses[index].Plan.Room ) 

elementC  select  Locallnstructor 

from  X  in  ScheduleClasses[index].taught_by ) 

OutputC  Locallnstructor.LastName ) 

end  loop 


The  student  information  is  obtained  by  selecting  an  instance  of  a  student  with 
InputSSAN  from  the  collection  of  students.  Next,  a  set  of  sections  is  created, 
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ScheduleClasses,  from  the  Student-Quarter-Section  tuple  by  selecting  on  InputSSAN  and 
InputTerm.  This  query  on  the  ternary  association  assumes  the  mapping  of  a  ternary 
association  is  provided  for  as  discussed  earlier  in  Chapter  III.  The  set  of  sections  is 
traversed  from  the  first  instance  of  section  to  the  last.  Additional  traversals,  nested  within 
the  outer  for-loop,  provide  related  section  information,  such  as,  the  course  title,  number  of 
credit  hours,  and  the  instructor. 

The  OQL  as  defined  in  the  ODMG-93  standard  is  SQL-like.  The  difference  at  the 
programmer  level  is  not  having  to  deal  with  table  operations.  The  programmer  must  be 
familiar  with  the  object  model  to  know  which  objects  to  query  and  relationships  to 
traverse.  The  ODMG-93  standard  is  a  way  of  bridging  from  today's  database  binding  to  a 
more  robust,  programming  language-like  fijture  binding.  This  future  binding  will  require  a 
complex  implementation  allowing  programmers  to  use  the  same  pointer  for  either  transient 
or  persistent  class  instances  and  a  sophisticated  query  language  interpreter  to  locate,  bind, 
and  execute  the  methods  for  query  functions.  A  pseudo-code  example  of  this  future 
binding  to  construct  the  student  schedule  queries  for  a  student's  name  and  course 
information  is  presented  below: 


LocalStudent  :  Student  :=  students!  SSAN  =  InputSSAN  ] 

OutputC  LocalStudent.First_Name,  LocalStudent.Middle_Initial,  LocalStudent.Last_Name, 
LocalStudent.  Box  Number  ) 

ScheduledClasses  :  set("Section") 

ScheduledClasses  ;=  sections!  class  roster  Student!  SSAN  =  InputSSAN  ] 

and  offered  in  Quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ]  } 

LocalCourse  :  Course 

LocalDepartment  :  Department 

LocalBuilding  :  Building 

Locallnstructor  :  Faculty 

for  index  in  llrst(ScheduleClasses) ..  last(ScheduleClasses)  loop 

LocalCourse  :=  courses!  has  Section!  ScheduledClassesfindex]  ]  ] 

LocalDepartment  ;=  departments!  offer  Course!  LocalComse  ]  ] 

LocalBuilding  ;=  buildings!hold  Section!  ScheduledClasses!index]  ]  ] 
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Locallnstructor  :=  faculty[teaches  Section[ScheduledClasses[index]  ]  ] 

LINK_ATTRIBUTE  ;=  TERNARY_RELATIONSHIP[  Student[  SSAN  =  InputSSAN  ], 
Quarter(  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ], 
Section[  ScheduledClasses  [index]  ] 

LINKATTRIBUTES  :=  LINK_RELATIONSHIP[  Section[  ScheduledClasses  [index]  ], 
Building[  LocalBuilding  ]  ] 

Output(  LocalDepartment.  Symbol,  LocalCourse.Number, 

ScheduledClasses[index] .  Symbol,  LocalCourse.Title,  LocalCourse.  CreditHours, 
LINK_ATTRIBUTE.Type,  LINK_ATTRIBUTES.Days, 

LINK  ATTRIBUTES.Start  Time,  LINK  ATTRJBUTES.End  Time, 
LocalBuilding.Number,  LINK  ATTRIBlJTES.Room, 
Locallnstructor.LastName ) 

end  loop 


In  the  future  binding  example,  the  LocalStudent  is  declared  a  student  type  and 
assigned  the  value  of  the  instance  of  a  student  from  the  collection  of  students  whose 
SSAN  is  equal  to  the  InputSSAN.  Relevant  student  information  can  be  obtained.  In  the 
next  query,  a  collection  of  sections,  ScheduleClasses,  is  created  for  the  student  by  forming 
a  predicate  from  InputSSAN  and  InputTerm.  The  ScheduleClasses  collection  is  then 
traversed  much  like  an  array  in  a  programming  language.  This  handling  of  objects  in 
collections  allows  the  programmer  to  work  in  one  language  and  not  have  to  perform 
queries  in  a  database  language  and  functions  in  a  programming  language.  The  benefit  is 
that  programmers  can  learn  one  language,  and  effectively  use  these  'future  OQL'  bindings 
much  like  functions  within  the  programming  language.  These  functions  must  be  provided 
by  the  DBMS  and  would  be  used  like  I/O  programming  language  operations. 

Class  Roster.  The  class  roster  depicted  in  Figures  4.3  and  4.4  repeat  much 
of  the  same  information  and  many  of  the  same  objects  as  examined  in  Figures  4. 1  and  4.2, 
respectively.  Two  of  the  differences  encountered  in  the  class  roster  example  are  the 
addition  of  the  graduates  many-to-one  Student-Quarter  relationship  with  link  attribute 
Symbol  and  the  additional  attributes  for  Student  and  Degree,  such  as 
Program_Sequence_Code  and  Program_Code,  respectively.  Much  of  the  querying  and 
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SCHOOL: 

Year  Quarter;  Dates  Inclusive 

START  END 

COURSE  TITLE  HRS  INSTRUCTOR _ DAYS  TIME  TIME  BLDG  ROOM 


STUDENTS  rLAST  name,  first  m.1.>  SSAN  TYPE  PROGRAM  GRADUATION  CODE 


Figure  4.3  Class  roster 


Figure  4.4  Class  Roster  Object  Model 
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data  manipulation  will  resemble  that  already  performed  in  the  earlier  student  class  schedule 
example,  and  is  provided  in  more  detail  in  Appendix  A. 

The  following  excerpt  from  the  class  roster  algorithm  demonstrates  the  use  of  the 
new  attributes  and  graduates  association  with  link  attributes  (assume  a  user  input  of 
course  identifier  and  quarter  of  interest): 


For  each  student  instance; 

Output  Last  Name,  First  Name,  Middle  Initial,  SSAN,  and  Program  Sequence  Code. 
Output  Student-Section-Quarter  ternary  association  link  attribute  Type. 

Traverse  Student-Degree  pursues  association  to  obtain  instance  of  Degree. 

Output  ProgramCode. 

Traverse  Student-Quarter  graduates  association  to  obtain  instance  of  Quarter. 

Output  Year  and  link  attribute  Symbol. 


SQL  versus  OQL.  The  class  roster  comparison  traverses  the  new 
Student-Quarter  graduates  relationship  and  outputs  the  Program_Code  link  attribute.  In 
the  SQL  pseudo-code  example  provided  the  Program  Sequences  table  and  earlier 
View_Person_Resident  table  are  joined  and  the  student's  Program_Sequence_Code 
selected  from  the  set  of  students  whose  Program_Code,  Class_Code,  and  Year_Prefix  are 
equivalent  between  tables  and  the  student's  SSAN  matches  the  one  entered  by  the  user. 
The  pseudo-code  is  shown  below  for  the  addition  of  the  graduates  link  attribute 
association.  Assume  that  all  previous  tables  are  available  and  the  Program  Sequence 
table  has  also  already  been  created. 


Program_Sequences(  Program  Code,  Class  Code,  Year  Prefix,  Program_Sequence_Code ) 


select  Program  Sequence  Code 

from  Program  Sequences,  View  Person  Resident 
where  View  Person  Resident.  SSAN  =  LocalSSAN 

and  Program_Sequences.Program_Code  =  View_Person_Resident.Program_Code 
and  ProgramSequences.ClassCode  =  View_Person_Resident.Class_Code 
and  ProgramSequences.YearPrefix  =  View_Person_Resident.Year_Prefix 
Output(  ProgramSequenceCode ) 
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The  SQL  example  shows  that  without  embedded  pointers  to  define  relationships  at 
the  implementation  level  a  table  is  required  with  keys  allowing  for  a  relationship  among 
the  objects  to  .be  modeled  and  to  store  the  link  attribute  data.  In  much  the  same  way  the 
object  oriented  database  (as  expanded  for  link  attributes)  allows  the  user  to  select  the 
relationship  and  output  the  link  attribute.  The  pseudo-code  (with  proposed  OQL)  to 
construct  class  roster  is: 

select  LINKATTRIBUTE 
from  X  in  Students 
y  in  X.  graduates 

where  x  =  StudentRoster[index] 

Output(  LocalDegree.Program  Code,  LocalQuarter.Year,  LINKATTRIBUTE.  Symbol) 

In  contrast  to  these  SQL  and  OQL  approaches,  the  future  OQL  approach  will  need 
to  provide  the  functions  necessary  to  select  a  given  object  from  a  collection  identified 
through  the  relationship  given  a  predicate  identifying  a  single  instance  of  the  related  object 
or  an  instance  of  that  object.  The  pseudo-code  (with  proposed  'fijture  OQL')  to  construct 
class  roster  is: 

LocalDegree  :  Degree  :=  degree[  pursued_by  Student!  StudentRosterf  index]  ] 

LocalQuarter  :  Quarter  :=  quarter!  graduates  Student!  StudentRoster!  index]  ] 

LINK  ATTR  :=  LINK  RELATIONSHIP!  Section!  ScheduledClasses!  index]], 

Building!  LocalBuilding  ]  ] 

Output!  LocalDegree.Program  Code,  LocalQuarter.Year,  LINK  ATTR. Symbol ) 

Both  OQL  examples  demonstrate  that  much  like  relational  database 
implementations,  when  a  relationship  between  two  or  more  objects  is  required,  that 
relationship  must  be  defined  by  a  pointer  structure  between  the  two  objects. 

Summary.  This  chapter  has  presented  the  pseudo-code  implementation  for  the 
construction  of  a  student's  class  schedule  and  a  department's  (instructor's)  class  rosters 
assuming  the  user  provides  the  necessary  input  variable(s)  fi-om  which  to  construct  a 
predicate.  The  implementation  is  presented  for  both  a  relational  database  and  an  object- 
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oriented  database.  By  comparing  implementations  we  can  see  that  the  fundamental 
requirement  of  DBMSs  being  designed  to  the  ODMG-93  standard  is  to  provide  the 
programmer  with  the  functionality  necessary  to  make  the  database  and  the  programming 
languages  unified. 
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V.  Summary  and  Conclusions 


Summary.  The  most  important  result  of  this  research  is  the  AFITSIS  object 
modeling  technique  detailed  analysis  and  design.  The  analysis  resulted  in  the 
documentation  of  general  student  information  system  requirements,  multiple  object  models 
developed  to  capture  the  data  and  attributes  of  the  objects  involved  in  such  an  information 
system,  a  dynamic  model,  resulting  state  transition  diagrams,  capturing  the  control  aspects 
of  the  system,  and  the  functional  model,  resulting  in  data  flow  diagrams,  capturing  the 
functional  aspects  of  the  system.  The  design  resulted  in  the  presentation  of  the  mapping  of 
objects  and  associations  contained  in  an  object  model  DBMS. 

As  part  of  the  analysis  it  was  shown  that  the  ODMG-93  ODBMS  standard  does 
not  plan  for  direct  implementation  of  «-ary  relationships  or  link  attribute  modeling 
concepts.  To  meet  the  requirement  of  implementing  an  «-ary  relationship  a  modeling 
approach  was  presented  in  which  the  «-ary  relationship  is  abstracted  as  an  object.  This 
relationship  object  will  then  contain  all  the  associations  and  inverse  associations  with  the  n 
objects  forming  the  n-ary  relationship.  As  it  was  pointed  out  in  Chapter  III,  this  same 
modeling  approach  will  allow  the  modeling  of  link  attributes  on  any  relationship. 

This  research  has  compared  and  contrasted  the  two  different  implementation 
approaches  for  mapping  a  database  design  from  an  object  model  to  its  respective  database 
and  database  language,  relational  and  object  databases  and  SQL  and  OQL,  respectively. 
The  biggest  advantage  is  the  elimination  of  the  intermediate  table  model  required  for  the 
relational  database  implementation  and  allowing  the  implementation  to  map  directly  from 
the  object  model  to  the  database  language. 
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In  terms  of  having  the  ability  of  meeting  information  system  requirements  and 
comparing  the  ttvo  database  implementations,  there  seems  to  be  no  impact  in  adopting  an 
object-oriented  database  versus  a  relational  database.  As  discussed  in  Chapter  I,  Joseph 
points  to  five  principles  for  moving  to  the  next  generation  database: 

1 .  Lack  of  expressive  data  modeling.  Although  the  implementation  of  the  system 
with  relational  tables  prohibits  direct  modeling  of  complex  data  types  the  developers  and 
maintainers  are  able  to  work  around  this  by  storing  information  in  tables  and  extracting 
information  by  joining  tables  with  related  information  and  selecting  on  predicates. 

2.  Impedance  mismatch  does  not  exist  because  the  AFITSIS  application  is  built, 
maintained,  and  operates  in  the  SQL/Oracle  environment  to  which  it  is  specifically 
targeted.  A  mismatch  could  occur  if  for  some  unlikely  reason  the  database  was  required 
to  operate  outside  this  host  environment. 

3.  Interactive  performance  does  not  support  next  generation  applications.  The 
AFITSIS  implementation  does  inherit  the  expense  of  the  relational  query,  but  with  the 
speed  of  the  hardware  and  by  developers/maintainers  optimizing  queries  to  only  select  and 
pass  necessary  fields,  the  additional  expense  may  be  minimized.  From  the  end  user 
perspective  the  operations  performed  are  not  restrictive  in  performance  of  their  daily 
duties. 

4.  Mechanisms  to  support  long  transactions.  These  mechanisms  are  non-existent 
in  AFITSIS,  but  are  not  required.  Operations  required  of  the  database  are  of  fixed  length, 
with  known  input,  and  knovm  output.  The  transactions  within  AFITSIS  are  of  short- 
duration  with  little  or  no  user  interface.  The  user  simply  builds  a  request  for  information, 
such  as  a  student  schedule,  and  the  system  returns  the  request. 

5.  Lack  of  schema  evolution  mechanism.  Although  a  shortfall  in  AFITSIS,  the 
maintainers  and  administrators  work  around  this  limitation  by  developing  a  process  in 
which  database  versions  are  archived.  For  example,  when  students  graduate  from  AFIT 
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they  are  no  longer  active,  so  their  student  information  is  removed  from  the  Student 
Tracking  and  Registration  System  database  and  archived  in  an  'alumni'  file.  Developing 
this  process  allows  the  system  users  to  treat  all  data  in  a  single  state  -  the  current  state. 

Conclusions.  The  three  research  objectives,  as  stated  in  Chapter  I,  were: 

1 .  Research  current  AFITSIS  requirements,  design,  and  implementation. 
Document  current  system  performance  benchmarks  and  maintainability  metrics  for 
comparison  with  prototype  system. 

2.  Use  object-oriented  methods  to  design  and  implement  an  object-oriented 
database  management  system  (OODBMS)  prototype  system.  Use  current  requirements 
as  stated  by  AFIT/SC  and  STARS  users  (performance  and  user  interface  requirements). 
The  design  structure  will  be  created  with  possible  upgrades  in  mind. 

3.  Test  OODBMS  prototype  against  current  requirements.  Compare  performance 
benchmarks  and  maintainability  predictions  with  current  RDBMS. 

The  research  was  successful  in  about  half  of  the  original  objectives.  Research  of 
the  current  AFITSIS  operations  and  software  support  documentation  led  to  the  creation 
of  an  application  problem  statement.  Three  analysis  models,  object,  dynamic,  and 
functional  models  were  constructed  to  capture  the  requirements  of  the  information  system. 
Finally,  from  these  analysis  models  a  proof  of  concept  detailed  design  was  constructed  to 
show  how  the  information  contained  within  the  object  model  may  be  retrieved.  This  was 
presented  for  both  a  relational  database,  which  the  current  AFITSIS  is  built  upon,  and  a 
object  database  showing  possible  implementations  on  a  proposed  ODBMS  standard. 

Currently  no  ODBMSs  support  this  ODBMS  standard  and  the  advertised 
unification  of  database  and  programming  languages.  This  along  with  time  constraints 
prevented  a  working  prototype  from  being  implemented  with  which  to  compare  similar 
functionality  from  the  current  AFITSIS.  This  could  be  a  possible  area  in  which  future 
research  could  be  conducted. 
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There  are  four  main  conclusions  that  may  be  reached  from  this  research: 

1 .  Using  the  OMT  a  proposed  model  has  been  developed  with  which  a  student 
tracking  and  registration  system  application  could  be  developed. 

2.  Examples  have  shown  that  an  implementation  of  the  information  system 
application  is  possible  with  either  a  relational  or  object-oriented  database  management 
system. 

3 .  Examples  demonstrate  that  removal  of  the  table  modeling  level  of  design  allows 
for  more  straight-forward  implementation  of  database  applications;  two-levels  of  mapping 
versus  three.  This  should  lead  to  design  documentation  matching  implementation  more 
closely  which  will  aid  in  both  development  and  maintenance  of  database  applications. 

4.  Future  object  database  binding  will  go  a  long  way  in  solving  the  "impedance 
mismatch"  principle  of  implementing  database  applications. 

Future  Plans  for  AFITSIS.  AFIT/SC  has  recently  acquired  the  hardware 
necessary  to  upgrade  versions  of  the  AFITSIS  database,  with  others  to  follow  at  a  later 
date,  and  the  AFIT/SCV  personnel  are  preparing  to  perform  the  hardware  migration  and 
software  version  updates.  This  planned  upgrade  will  allow  AFITSIS  to  move  from 
PL/SQL  version  6.0  to  version  7,  Oracle*Forms  version  2.3  to  version  4,  and 
Oracle*Menus  version  4. 1  to  version  5.  This  upgrade  effort  most  likely  will  aid  in  the 
'look  and  feel'  of  the  AFITSIS  system,  but  software  maintainability  at  best  will  remain 
constant.  In  the  conversion  of  the  existing  code  it  is  estimated  that  30%  of  the  code  will 
need  some  changes  in  order  for  the  information  system  to  operate  in  the  new  environment. 
This  modification  obviously  involves  a  substantial  amount  of  effort  and  could  provide  an 
area  for  future  research.  Specifically  in  the  area  of  code  reuse,  automated  code 
generation,  measuring  performances,  and  the  drawbacks  and  benefits  to  performing  the 
upgrade. 
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The  maintainability  issue  needs  to  be  studied  further  in  terms  of  what  the  Air  Force 
currently  spends  and  is  projected  to  spend  in  life-cycle  maintenance  and  support  costs 
versus  what  it  would  cost  to  re-engineer  an  information  system  and  its  associated  life- 
cycle  costs.  If  the  latter  option  is  viable  this  research  would  be  a  valuable  asset  in 
beginning  this  effort.  Suggestions  for  re-engineering  the  system  are:  identify  a 
requirements  group  early  in  the  process  made  up  of  current  maintainers,  users,  and 
developers  to  define  preliminary  system  requirements,  prototype  the  dynamic  aspects  of 
the  system  allowing  the  users  to  provide  feedback  on  success  of  implementation  decisions, 
prototype  report  designs  and  user  required  queries,  and  baseline  the  system  requirements. 
The  OMT  models  provided  as  part  of  this  research  provide  the  developers  a  framework 
from  which  to  begin  requirements  definition  and  dynamic  prototyping.  All  three  of  the 
models  should  be  able  to  be  used  directly  with  modifications  made  according  to  changing 
requirements  and  changes  to  dynamic  operations.  The  object  and  functional  models  will 
most  likely  need  extending  to  accept  the  additional  forms  and  reports  that  were  not 
captured  as  part  of  this  research  effort. 

This  approach  to  re-engineering  the  AFIT  information  system  is  important  for 
three  reasons:  (1)  the  end  user  is  involved  in  the  application  development  making  their 
recommendations  a  top  priority,  (2)  as  opposed  to  the  original  development  effort,  a 
majority  of  requirements  are  known  allowing  developers  more  flexibility  in  their 
implementation,  and  (3)  object-oriented  principles  and  DBMS  should  provide  better 
maintainable  software. 

Malcolm  Atkinson  estimated  as  much  as  30%  of  a  program's  lines  of  code  could  be 
eliminated  by  having  a  single  unified  system  in  which  programming  and  database 
languages  are  transparent  [3:33].  When  ODBMSs  based  on  the  ODMG-93  standard 
finally  make  it  to  market,  an  interesting  case  study  would  be  to  compare  the  effort 
required  to  generate  an  identical  application  based  upon  a  RDBMS  versus  an  ODBMS. 
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An  argument  for  the  use  of  object-oriented  analysis,  design,  and  programming  is  the  ability 
to  reuse  objects.  Corporate  America  and  the  DoD  have  been  trying  to  justify  and  estimate 
the  savings  of  reuse  and  object-oriented  approaches.  Despite  all  this  attention,  not  a  single 
study  exists  on  the  development  of  an  application  using  two  approaches  -  one  with  reuse 
and  the  other  without. 
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APPENDIX  A 


AFITSIS  DESIGN 

Appendix  A  contains  the  OMT  object,  dynamic,  and  functional  models  necessary 
to  implement  a  student  tracking  and  registration  system.  The  object  model  consists  of 
object  diagrams  for  school,  person,  and  course  views.  The  dynamic  model  has  an 
additional  scenario,  the  related  event  trace,  an  application  event  flow  diagram,  a  complete 
collection  of  state  diagrams,  and  the  resulting  state  transition  table.  The  functional  model 
consists  of  data  flow  diagrams  for  the  information  system  application.  Following  these 
OMT  models  is  a  design  mapping  comparison  for  implementing  an  association  OMT 
modeling  concept  in  a  RDBMS  versus  an  ODBMS.  Then  examples  are  provided  along 
with  possible  algorithms  for  extracting  data  from  the  object  models  presented  earlier. 
Finally,  data  dictionary  descriptions  are  provided  capturing  the  attributes  of  the  objects 
and  the  range  of  values  permitted. 
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PERSON 


See  Figure  A. 2 


certifies 


ROOM 


See  Figure  A.3 
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See  Figure  A.3 


DEGREE 
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Title 
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located  in 
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Date 


presented 


AWARD 


Name 


Figure  A.  1  School  Object  Diagram 
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ORGANIZATION 
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GradePoints 
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EndDate 
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Figure  A.2  Person  Object  Diagram 
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PERSON 
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COURSE 


Number 
Title 

CreditHours 
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taught_by 


teaches 
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See  Figure  A. 2 
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BOOK 


Title 

Author 

Publisher 
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_ ! 
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SECTION 
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Figure  A.4  Course  Object  Diagram 


First  three  steps  same  as  Figure  3.10. 

The  application  presents  student  user  with  menu  of  operations  (create 
schedule,  modify  schedule,  view  schedule,  print  schedule);  user  selects 
view  schedule. 

The  application  sends  system  view  schedule  request. 

The  system  passes  application  the  requested  student  schedule. 

The  application  displays  schedule  and  presents  student  user  with  a  submenu  of 
operations;  the  user  selects  print  schedule. 

The  application  prints  schedule. 

The  application  presents  user  with  menu  of  operations;  the  user  selects  exit. 

The  application  terminates. _ 

Figure  A.5  Student  user  scenario 
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enter  section  and  quarter 


request  number  to  be  printed 


enter  number 


request  data  (student  sched^)] 
return  data  (student  schedule) ; 


Figure  A.7  Application  event  flow  diagram 


StartApplication 


UserLogin(name) 


Loginlnvalidriogin  Denied” 


f 

[EXIT] 

IN_USE 

1 

Figure  A.8  Application  state  diagram 


[EXIT]  [EXIT] 


Figure  A.9  Substates  of  In_Use  state 


Figure  A.10  Possible  generalization  of  Present  Options  Menu  State 
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[TRUE][CREATE]rData  Exist" 


PROCESS  SELECTION 


Request(selectio^  SELECT  FORM 

^  do:  display  form  ^  5  . 

’  do:  look  for  object 


[FALSE][CREATE] 


CREATE 

SUBMENU 


[CANCEL] 


[COMMIT] 


[REPEAT] 

SUBMENU 


[MAIN  MENU] 


Figure  A.  11  Partial  substates  of  Process  Selection  state 

ExceptionHandling  [TURE][CREATE]rData  Exists’ 

ExceptionHandling  [FALSE]  {[MODIFY][PRINT][DISPLAY][DELETE]}/”Data  Does  Not  Exist” 


PROCESS  SELECTION 


[REPEAT] 


Request(selectioi^  5£L£Cj  PORM 

^  do:  display  form 


[TRUE][DELETE] 


[MAIN  MENU] 


[CANCEL]  [MAIN  MENU]  [CANCEL] 


Figure  A.  12  Process  Selection  state 
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terminal 


Check  Database 


Display  Option  Menu 
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Display  Option  Menu 
Display  Option  Menu 
Display  Option  Menu 
Display  Option  Menu 
Modify/Submenu 
Print/Submenu 
Display/Submenu 
Delete/Submenu 


Save  Data/Submenu 
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“Data  Exists” 


“No  Data  Exists” 
“No  Data  Exists” 
“No  Data  Exists” 
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Table  A.1  State  transition  table  for  Application 


/(userjype) 


Figure  A.  13  State  diagram  for  Database  System 


Table  A.2  State  transition  tal 

)le  for  I 

database  System 

Current  State 

Event 

Parameters 

Guard 

Next  State 

Action 

Idle 

Idle 

User  Verification 

Process  Request 

User  Verification 

user  type 

Idle 

(data) 

Idle 

Figure  A,  14  STARS  Application  Level  0  DFD 


Figure  A.15  Perform  Action  Level  1  DFD 
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DATABASE 

selection 

Valid  (selection) 

Figure  A.16  Offer  Menu  Options  Level  2  DFD 


FORM 


Figure  A.  17  Handle  Selection  Level  2  DFD 
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(selection) 


Figure  A.  18  Do  Event  Level  3  DFD 


(selection) 


(selection) 


data 


option 


Figure  A.20  Modify  Level  4  DFD 


DATABASE 


Figure  A.21  Save  Level  5  DFD 


VDU 


Figure  A.22  Display  Level  4  DFD 
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Figure  A.23  Print  Level  4  DFD 


Figure  A.24  Delete  Level  4  DFD 
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Object 

Model 


Table 

Model 


SQL 

Code 


Create  Person  Table  (Figure  3.28) 

Create  Student  and  Degree  Tables,  similar  to  Figure  3.28 


pursue  Tal 

jle 

Attribute  name 

Nulls 

Domain 

person-ID 

N 

ED 

degree-ID 

N 

ID 

Candidate  Key:  (person-ED) 

Primary  Key:  (person-DD) 

Frequently  accessed:  (person-ID)  (degree-ID) 


Create  table  and  indexes  for  Person  (Figure  3.28) 

Create  table  and  indexes  for  Degree  (similar  to  Figure  3.28) 

CREATE  TABLE  pursues 

(  person-ED  ID  not  null, 

degree-ID  ID  not  null, 

PRIMARY  KEY  (person-ED,  degree-ID) 

FOREIGN  KEY  (degree-ID)  REFERENCES  Degree, 
FOREIGN  KEY  (person-ID)  REFERENCES  Person  ); 

Figure  A.25  Mapping  association  to  relational  database 
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Object 

Model 


OQL 


STUDENT  b 


pursues  pursued_by 


DEGREE 


INTERFACE  Student 
(  EXTENT  students 

KEYS  SSAN,  last_name  ) 

{ 

ATTRIBUTE  String  last_name; 

ATTRIBUTE  String  first_name; 

ATTRIBUTE  Character  middlejnitial; 

ATTRIBUTE  Integer(9)  SSAN; 

ATTRIBUTE  Integer(4)  Box_Number; 

RELATIONSHIP  Degree  pursues  INVERSE  Degree:: pur sued_by  } 

Note:  The  1:N  pursues  relationship  will  have  an  effect  on  Degree.pursued_by. 

Figure  A.26  Mapping  association  to  object-oriented  database 
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Student  Class  Schedule  Report; 

Student  Name 
Box  Number 


Year  Quarter:  Dates  Inclusive 


GRD  START  END 

COURSE  TITLE _ HRS  TYP  DAYS  TIME  TIME  BLDG  ROOM 


SCHOOL:  DEGREE: 

CLASS:  PROGRAM: 


Figure  A.27  Student  Class  Schedule  Object  Model 


INSTRUCTOR 


BUILDING 

Number 
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Algorithm  to  construct  student  schedule  from  object  diagram; 

Build  schedule  on  student's  identification  and  quarter.  Input  student's  social  security  number  and  quarter. 
Obtain  Instance  of  Student  Object  and  Quarter. 

Output  Student's  First  Name,  Middle  Initial,  Last  Name,  and  Box  Number. 

Output  Year,  Term,  Start  Date  and  End  Date  for  instance  of  quarter. 

(With  student  id  and  quarter)  Traverse  Student-Section-Quarter  enrolled  in  ternary  association 
to  get  instances  of  sections  student  is  enrolled  in. 

For  each  section  instance: 

Output  Section  Symbol. 

Output  enrolled  in  ternary  association  linked  attribute  Grade  Type. 

Traverse  Section-Course  belongs  to  association  to  get  instance  of  Course. 

Output  Course's  Number,  Title,  and  Credit  Hours. 

For  each  course  instance: 

Traverse  Course-Department  offers  association  to  obtain  instance  of  Department. 
Output  Department  symbol. 

Traverse  Section-Faculty  taught  by  association  to  obtain  instance  of  Faculty. 

Output  Faculty's  Last  Name. 

Traverse  Section-Room  meets_in  association  to  obtain  instance  of  Room. 

Output  Building  Number. 

Output  meets  in  linked  attributes  Room,  Days,  Start  Time,  and  End  Time. 

Traverse  Student-Degree  pursues  association  to  obtain  instance(s)  of  Degree. 

Output  Degree  Title  (Degree),  Status  (Class)  and  Type  (Program). 

Traverse  Student-Department  assigned  to  association  to  obtain  instance  of  Department. 
Traverse  Department-School  part_of  aggregation  to  obtain  instance  of  School. 

Output  School. 

SQL  versus  OQL  Comparison 

Assume  inputs  from  user  are  InputSSAN  znd  InputTerm. 

Assume  following  relational  tables  exist; 

Course_Taught_By(  Course  TaughtOOTerm  Code,  Course_Prefix_Code,  Course  Number, 
Course_Section,  Faculty_SSAN ) 

Grade_History(  Course  Prefix  Code,  Course_Number,  Course  Section,  ScheduleOOTerm  Code, 
SSAN,  Credit  Hours,  Grade_Type_Code  ) 

Schedule(  Course  Prefix  Code,  Course  Number,  Course  Section,  Comse  Start  Time, 

Course  End  Time,  Course_Title,  Day  Code,  ScheduleOOBuilding  Code, 

ScheduleOORoom  Code,  ScheduleOOTerm  Code ) 

Person(  SSAN,  First_Name,  Last  Name,  Middle  lnitial ) 

Resident_Student(  SSAN,  Classification  Code,  AFIT  Degree  Code,  Program  Code,  Box  Number, 
Selected_Type_Code ) 

Terms(  TermCode,  Term ) 

Term_Date(  Term  Code,  Term_Start_Date,  Term  End  Date ) 

AFIT_School_Valid(  AFIT_School_Code,  AFIT_School ) 

AFIT_Degree_Valid(  AFIT_DegTee_Code,  AFITDegree ) 

Classification_Valid(  Classification  Code,  Classification ) 

Program(  ProgramCode,  Program ) 

Pseudo-code  (with  SQL)  to  construct  student  schedule; 
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create  view  View_Person_Resident(  SSAN,  Last  Name,  First  Name,  Middle  lnitial, 
Box_Number )  as 

(select  SSAN,  Last  Name,  First  Name,  Middle  lnitial 

from  Person,  Resident  Student 

where  Person.SSAN  =  Resident_Student.SSAN ) 

select  First_Name||'  '||Middle_Initiall|'  '|lLast_Name,  Box_Number,  Term||' :  '||Term_Start_Date||' 
to '  ||Term_End_Date 
into  Name,  Box  Number,  Term  info 

from  ViewPersonResident,  Terms,  TermDate 
where  View_Person_Resident.SSAN  =  InputSSAN 
and  Terms.Term_Code  =  InputTerm 
and  TermDate.TermCode  =  InputTerm 

C)utput(  Name,  Box  Number,  Term  info ) 

select  Grade_History.Course_Prefix_Code,  Grade  History.Course  Number, 

Grade  Histoiy.Course  Section,  Course  Title,  Grade  History.Credit  Hours, 

Grade  Type  Code,  NVL(Day_Code,'TBA'),  Course  Start  Time,  Course  End  Time, 
NVL(ScheduleOOBuilding_Code,  'TBA'),  NVL(ScheduleOORoom_Code,  'TBA') 
into  Course  Prefix  Code,  Course_Number,  Course  Section,  Course  Title,  Credit  Hours, 
Grading  Type,  Days,  Start  Time,  End  Time,  Building,  Room 
from  Grade  History,  Schedule 
where  Grade_History.  SSAN  =  /MpM/5S4Af 
and  Grade_History.ScheduleOOTerm_Code  =  /npM/rer/n 
and  Schedule.  ScheduleOOTerm_Code  =  //7pMirem 
and  Grade_History.Course_Prefix_Code  =  Schedule.  Course_Prefix_Code 
and  Grade_History.Course_Number  =  Schedule.Course_Number 
and  Grade_History.Course_Section  =  Schedule.  Course_Section 

Output(  Course_Prefix_Code,  Course  Number,  Course_Section,  Course_Title,  Credit  Hours, 
Grading  Type,  Days,  Start  Time,  End  Time,  Building,  Room ) 

LocalCourse  Prefix  Code  =  Course  Prefix  Number 
LocalCourse_Number  =  CourseNumber 
LocalCourse  JSection  =  CourseSection 

select  Last_Name 
into  Instructor 

from  Person,  Course  Taught  By 

where  Person.  SSAN  =  Course_Taught_By.Faculty_SSAN 

and  Course_Taught_By.Course_TaughtOOTerm_Code  =  /n/>Mtrer/n 

and  Course  Taught  By.Course  Prefix  Code  =  LocalCourse  Prefix  Code 

and  Course_Taught_By.Course_Number  =  LocalCourse  Number 

and  Course  Taught  By.Course  Section  =  LocalCourse  Section 

Output(  Instructor ) 

select  AFITSchool 
into  School 

from  AFIT  School  Valid,  Resident  Student 
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where  SSAN  =  InputSSAN 

and  AFIT_School_Valid.AFIT_School_Code  =  Resident_Student.Selected_Type_Code 

Output(  School ) 

select  AFIT_Degree 
into  Degree 

from  AFIT_Degree_Valid,  Resident_Student 
where  SSAN  =  InputSSAN 

and  AFlTDegreeValid.AFITDegreeCode  =  ResidentStudent.AFITDegreeCode 

Output!  Degree ) 

select  Classification 
into  Class 

from  ClassificationValid,  ResidentStudent 
where  SSAN  =  InputSSAN 

and  Classification  Valid.Classification  Code  =  Resident_Student.Classification_Code 
Output!  Class ) 
select  Program 

from  Program,  Resident_Student 
where  SSAN  =  InputSSAN 

and  Program.Program_Code  =  ResidentStudent.ProgramCode 
Output!  Program ) 


Pseudo-code  (with  proposed  OQL)  to  construct  student  schedule: 

Assume  inputs  from  user  are  InputSSAN  ^xi^i  InputTerm. 

select  distinct  LocalStudent 
from  X  in  Students 
where  x.SSAN  =  InputSSAN 

Output!  LocalStudent-First  Name,  LocalStudent.Middle  lnitial,  LocalStudentXast  Name, 
LocalStudent.  Box  Number  ) 

select  distinct  LocalTerm 
from  X  in  Quarters 
where  x.Term  =  InputTerm.  Term 
and  x.Year  =  InputTerm.  Year 

Output!  LocalTerm.Term,  LocalTerm. Year,  LocalTerm.  Start_Date,  LocalTerm.End_Date ) 

select  ScheduledClasses 

from  X  in  Students.Registration 
y  in  Quarters.Registration 
where  x.SSAN  =  InputSSAN 
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and  y.Term  =  InputTerm.  Term 
and  y.Year  =  InputTerm.  Year 

for  index  first(ScheduleClasses)  to  last(ScheduleClasses)  loop 

element(  select  LocalCourse 

from  X  in  ScheduleClasses[index].belongs_to) 

select  LINKATTRIBUTE 
from  X  in  Sections 
y  in  Quarters 
z  in  Students 

where  x  =  ScheduleClasses[index] 
and  y.Term  =  InputTerm.Term 
and  y.Year  =  InputTerm.  Year 
and  z.SSAN  =  InputSSAN 

select  LocalDepartment 
from  X  in  Course 

y  in  x.oflfered_by 
where  x  =  LocalCourse 

Output(  LocalDepartment.  Symbol,  LocalCourse.Number, 

ScheduleClasses[index].  Symbol,  LocalCourse.Title,  LocalCourse.CreditHours, 
LINK_ATTRIBUTE.Type ) 

select  LINK_ATTRIBUTES 
from  X  in  Sections 
y  in  x.meetsjn 

where  x  =  ScheduleClasses[index] 

select  LocalBuilding 

from  X  in  ScheduleClassespndex] 
y  in  x.meets  in 
where  x  =  LocalCourse 

Output(  LINK_ATTRIBUTES.Days,  LINK_ATTRIBUTES.Start_Time, 
LINK_ATTRIBUTES.End_Time,  LocalBuilding.Niunber, 
LINKATTRIBUTES.Room ) 

element(  select  Locallnstructor 

from  X  in  ScheduleClasses[index].taught_by ) 

Output(  Locallnstructor.  LastName ) 


end  loop 

select  distinct  LocalDegree 
from  X  in  Students 
y  in  x.pursues 

where  x.SSAN  =  InputSSAN 

select  distinct  LocalDepartment 
from  X  in  Students 
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y  in  x.assigned  to 
where  x.SSAN  =  InputSSAN 


select  distinct  LocalSchool 
from  X  in  Students 

y  in  x,assigned_to 
z  in  y.partof 

where  x.SSAN  =  InputSSAN 

Output(  LocalSchool.  School,  LocalDegree.Title,  LocalDegree.  Status,  LocalDegree.Type ) 

Pseudo-code  (with  proposed  OQL)  to  construct  student  schedule: 

Assume  inputs  from  user  are  InputSSAN  Zind  InputTerm. 

LocalStudent  ;  Student  ;=  students!  SSAN  =  InputSSAN  ] 

Output(  LocalStudent.First_Name,  LocalStudent.Middlelnitial,  LocalStudent.LastName, 
LocalStudent.  Box  Number ) 

LocalTerm  :  Quarter  :=  quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ] 

Output(  LocalTerm.  Term,  LocalTerm. Year,  LocalTerm.  Start_Date,  LocalTerm.End_Date ) 

ScheduledClasses  :  set("Section") 

ScheduledClasses  :=  sections!  class_roster  Student!  SSAN  =  InputSSAN  ] 

and  ofFered_in  Quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ]  } 


LocalCourse 

LocalDepartment 

LocalBuilding 

Locallnstructor 


Course 

Department 

Building 

Faculty 


for  index  in  first(ScheduleClasses) ..  last(ScheduleClasses)  loop 

LocalCourse  :=  courses!  has  Section!  ScheduledClasses!index]  ]  ] 

LocalDepartment  :=  departments!  offer  Course!  LocalCourse  ]  ] 

LocalBuilding  :=  buildings!hold  Section!  ScheduledClasses !index]  ]  ] 

Locallnstructor  :=  facultypeaches  Section!ScheduledClasses!index]  ]  ] 

LINK_ATTRIBUTE  :=  TERNARY_RELATIONSHIP!  Student!  SSAN  =  InputSSAN], 
Quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ], 
Section!  ScheduledClasses!index]  ] 

LINK_ATTRIBUTES  :=  LINK_RELATIONSHIP!  Section!  ScheduledClasses!index]  ], 
Building!  LocalBuilding  ]  ] 

Output!  LocalDepartment.  Symbol,  LocalCourse.Number, 

ScheduledClasses!index]. Symbol,  LocalCourse.Title,  LocalCourse. CreditHours, 
LINK_ATTRIBUTE.Type,  LINK_ATTRIBUTES.Days, 
LINK_ATTRIBlJTES.Start_Time,LINK_ATTRIBLrTES.End_Time, 
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LocalBuilding.Number,  LINK_ ATTRIBU I'H S . Room, 
Locallnstructor.LastName  ) 

end  loop 

LocalDegree  :=  degree[  pursued_by[Student  =  LocalStudent]  ] 

LocalDepartment  ;=  department[  has[Student  =  LocalStudent]  ] 

LocalSchool  :=  school[  made_up_ofITDepartnient  =  LocalDepartment]  ] 

Output(  LocalSchool.  School,  LocalDegree.Title,  LocalDegree.  Status,  LocalDegree.Type ) 
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Class  Roster; 


SCHOOL: 

Year  Quarter:  Dates  Inclusive 

START  END 

COURSE  TITLE  HRS  INSTRUCTOR _ DAYS  TIME  TIME  BLDG  ROOM 


STUDENTS  rLAST  NAME.  FIRST  M.I.1  SSAN  TYPE  PROGRAM  GRADUATION  CODE 


Figure  A.28  Class  Roster  Object  Model 
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Algorithm  to  construct  class  roster  from  object  diagram: 

Build  class  roster  on  course  identification  (Department  Symbol,  Course  Number,  Course  Section)  and 
Quarter.  Input  course  identification  and  quarter. 

Obtain  Instance  of  Department,  Course,  Section,  and  Quarter. 

Output  Department  Symbol,  Course  Number,  Section  Symbol,  Course  Title,  and  CreditHours. 
Traverse  Department-School  part  of  aggregation  to  obtain  instance  of  School. 

Output  School  Name. 

Output  Year,  Term,  Start  Date  and  End  Date  for  instance  of  quarter. 

Traverse  Section-Faculty  taught  by  association  to  obtain  instance  of  Faculty. 

Output  Faculty's  Last  Name. 

Traverse  Section-Building  meets  in  association  to  obtain  instance  of  Building. 

Output  Building  Number. 

Output  meets  in  linked  attributes  Days,  Start  Time,  End  Time,  and  Room. 

(With  Course  Section  and  quarter)  Traverse  Student-Section-Quarter  ternary  association  to  get 
instances  of  students  enrolled  in  section  for  the  quarter. 

For  each  student  instance: 

Output  Last  Name,  First  Name,  Middle  Initial,  SSAN,  and  ASC  Code. 

Output  Student-Section-CJuarter  ternary  association  link  attribute  Type. 

Traverse  Student-Degree  pursues  association  to  obtain  instance  of  Degree. 

Output  ProgramCode. 

Traverse  Student-Quarter  graduates  association  to  obtain  instance  of  (Quarter. 

Output  Year  and  link  attribute  Symbol. 

SQL  versus  OQL  Comparison 

Assume  inputs  from  user  are  InputCourse  Prefix,  InputCourse_Number, 

InputCourse  Section,  and  InputTerm. 

Assume  following  relational  tables  exist: 

Coiuse_Taught_By(  Course_TaughtOOTerm_Code,  Course  Prefix  Code,  Course  Nmnber, 
Course_Section,  Faculty_SSAN ) 

Grade_History(  Course  Prefix  Code,  Course  Number,  Course  Section,  ScheduleOOTerm  Code, 
SSAN,  Credit  Hours,  Grade  Type  Code ) 

Schedule(  Course  Prefix  Code,  Course  Number,  Course  Section,  Course  Start  Time, 

Course  End  Time,  Course  Title,  Day  Code,  ScheduleOOBuilding  Code, 

ScheduleOORoom  Code,  ScheduleOOTerm  Code,  AFIT  School  Code ) 

Person(  SSAN,  First  Name,  Last_Name,  Middle  lnitial ) 

Resident_Student(  SSAN,  Program  Code,  Class  Code,  Program  Year  Prefix ) 

Terms(  TermCode,  Term ) 

Term_Date(  Term  Code,  Term  Start  Date,  Term  End  Date  ) 

AFIT_School_Valid(  AFIT  School  Code,  AFIT  School ) 

Program_Sequences(Program_Code,  Class  Code,  Year  Prefix,  Program  Sequence  Code ) 

Pseudo-code  (with  SQL)  to  construct  class  roster: 

select  AFIT  School 
into  School 

from  AFIT  School  Valid,  Schedule 

where  AFITSchoolValid.AFITSchoolCode  =  Schedule.AFITSchoolCode 
Output(  School ) 
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select  SSAN,  Course  Title,  Grade  History.Credit  Hours,  Grade  Type  Code, 
NVL(Day_Code,'TBA'),  Course_Start_Time,  Course  End  Time, 
NVL(ScheduleOOBuilding_Code,  'TBA'),  NVL(ScheduleOORoom_Code,  'TBA') 
into  Course  Prefix  Code,  Course  Number,  Course  Section,  Course  Title,  Credit  Hours, 
Gruding  Type,  Days,  Start_Time,  End  Time,  Building,  Room 
from  Grade_History,  Schedule 

where  GradeHistory.ScheduleOOTermCode  =  InputTerm 
and  Schedule.  ScheduleOOTerm  Code  = 
and  Grade  History.Course  Prefix  Code  =  InputCourse  Prefix 
and  Grade  History.Course  Number  =  InputCourse_Number 
and  Grade  History.Course  Section  =  //i/?MrCoMr5e_5'ect/on 
and  Schedule.Course  Prefix  Code  =  Grade  History.Course  Prefix  Code 
and  Schedule. Course  Number  =  Grade  History.Course  Number 
and  Schedule.Course_Section  =  Grade  History.Course  Section 
Output(  Course  Prefix  Code,  Course  Number,  Course  Section,  Course  Title,  Credit  Hours, 
SSAN,  Grading  Type,  Days,  Start  Time,  End  Time,  Building,  Room ) 

Local  SSAN  =  Grade  Histoiy.SSAN 

create  view  View_Person_Resident(  SSAN,  Last  Name,  First  Name,  Middle  lnitial, 

Class  Code,  Program  Code,  Program  Year  Prefix )  as 

(select  SSAN,  Last  Name,  First  Name,  Middle  lnitial,  Class_Code,  Program_Code, 

Program_Year_Prefix 

from  Person,  Resident_Student 

where  Person. SSAN  =  Resident_Student.SSAN ) 

select  First_Name|r  '||Middle_Initial|l'  '|iLast_Name,  Class_Code,  Term||' :  '||Term_Start_Date|r  to 
'  ||Term_End_Date 
into  Name,  Class_Code,  Term  info 

from  View_Person_Resident,  Terms,  TermDate 
where  View_Person_Resident.SSAN  =  LocalSSAN 
and  Terms.Term  Code  =  InputTerm 
and  TermDate.TermCode  =  InputTerm 
Output(  Name,  Term  info,  Class  Code ) 

select  Last  Name 
into  Instructor 

from  Person,  Course  Taught  By 

where  Person.  SSAN  =  Course  Taught  By.FacuIty  SSAN 
and  Course_Taught_By.Course_TaughtOOTerm_Code  =  /w/7Mtrerw 
and  Course_Taught_By.Course_Prefix_Code  =  InputCourse  Prefix 
and  Course_Taught_By.Course_Number  =  InputLocalCourse  Number 
and  Course  Taught  By.Course  Section  =  InputCourse  Section 
Output(  Instructor ) 

select  ProgramSequenceCode 

from  Program  Sequences,  View  Person  Resident 
where  View_Person_Resident.SSAN  =  Loca/5&4A^ 

and  ProgramSequences.ProgramCode  =  View_Person_Resident.Program_Code 
and  Program_Sequences.CIass_Code  =  View_Person_Resident.Class_Code 
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and  ProgramSequences.YearPrefix  =  ViewPersonResident.YearPrefix 
Output(  Program_Sequence_Code ) 

Pseudo-code  (with  proposed  OQL)  to  construct  class  roster: 

Assume  inputs  from  user  are  InputCourse  Prefix,  InputCourse  Number, 

InputCourse  Section,  and  InputTerm. 

select  distinct  LocalSchool 
from  X  in  Department 
y  in  x.part  of 

where  x.  Symbol  =  InputCourse  Prefix 
Output(  LocalSchool.  School ) 

select  distinct  LocalTerm 
from  X  in  Quarters 
where  x.Term  =  InputTerm.  Term 
and  X.  Year  =  InputTerm.  Year 

Output(  LocalTerm.Term,  LocalTerm. Year,  LocalTerm. Start_Date,  LocalTerm.End_Date  ) 

select  distinct  LocalDepartment 
from  X  in  Departments 
where  x.  Symbol  =  InputCourse  Prefix 

select  distinct  LocalCourse 
from  X  in  Courses 

where  x.Number  =  InputCourse _Number 

select  distinct  LocalSection 
from  X  in  Sections 

where  x.  Symbol  =  InputCourse  Section 

LocalSectionOutput(  LocalDepartment.  Symbol,  LocalCourse.Number,  LocalSection.  Symbol, 
LocalCourse.Title,  LocalCourse.CreditHours ) 

element(  select  Locallnstructor 

from  x  in  LocalSection.taught_by ) 

Output(  Locallnstructor.LastName  ) 

select  LINKA'i  I'RIBUTES 
from  X  in  Sections 
y  in  x.meets  in 

where  x  =  InputCourse  Section 

Output(  LINKATTRIBUTES.Days,  LINKATTRIBUTES.Start  Time, 
LINKATTRIBUTES.End_Time,  LINKATTRIBUTES.Room ) 

select  LocalBuilding 

from  X  in  Sections 
y  in  x.meets  in 

where  x  =  InputCourse  Section 
Output(  LocalBuilding.Number ) 
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select  StudentRoster 

from  X  in  Sections.Registration 
y  in  Quarters.Registration 
where  's..SyvctoQ\  =  InputCourse  Section 
and  y.Term  =  InputTerm.  Term 
and  y.Year  =  InputTerm.  Year 

for  index  flrst(StudentRoster)  to  last(StudentRoster)  loop 

Output(  StudentRoster[index].Last_Name,  StudentRoster[index].First_Name, 
StudentRoster[index].Middle_Initial,  StudentRoster[index].SSAN, 
StudentRoster[index].Program_Sequence_Code ) 

select  LINKATTRIBUTE 
from  X  in  Sections 
y  in  Quarters 
z  in  Students 

where  x.  Symbol  =  InputCourse  Section 
and  y.Term  =  InputTerm.  Term 
and  y.Year  =  InputTerm.  Year 
and  z  =  StudentRoster[index] 

Output(  LINKATTRIBUTE.Type ) 

select  LocalDegree 

from  X  in  Students 
y  in  x.pursues 

where  x  =  StudentRoster[index] 

select  LocalQuarter 

from  X  in  Students 
y  in  X.  graduates 

where  x  =  StudentRosterpndex] 

select  LINKATTRIBUTE 
from  X  in  Students 
y  in  X.  graduates 

where  x  =  StudentRoster[index] 

Output(  LocalDegree.  ProgramCode,  LocalQuarter.Year,  LINKATTRIBUTE.  Symbol) 


end  loop 


Pseudo-code  (with  proposed  OQL)  to  construct  class  roster: 

Assume  inputs  from  user  are  InputCourse  Prefix,  InputCourse  Number, 

InputCourse  Section,  and  InputTerm. 

LocalSchool  :=  school!  made_up_of  Department!  Symbol  =  InputCourse  Prefix  ]  ] 

Output!  LocalSchool.  School ) 

LocalTerm  :  Quarter  :=  quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ] 
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Output(  LocalTerai-Term,  LocalTerm.Year,  LocalTerm.Start  Date,  LocalTerm.End  Date  ) 

LocalDepartment :  Department  :=  departments[Symbol  =  InputCourse  Prefix] 

LocalCourse  :  Course  :=  courses[  Number  =  InputCourse _Number  ] 

LocalSection  :  Section:=  sections[  Symbol  =  InputCourse _Section  ] 

OutputC  LocalDepartment.  Symbol,  LocalComse.Number,  LocalSection.  Symbol, 
LocalCourse.Title,  LocalCourse. CreditHours ) 

Locallnstructor  :  Faculty  :=  faculty[  teaches  Section[  LocalSection  ] 

Output(  Locallnstructor.LastName ) 

LocalBuilding  :=  buildings!  hold  Section!  LocalSection  ]  ] 

Output(  LocalBuilding.  Number ) 

LINK_ATTRIBUTES  ;=  LINK_RELATIONSHIPI  SecUon!  LocalSection  ], 

Building!  LocalBuilding  ]  ] 

Output(  LINK_ATTRIBUTES.Days,  LINK_ATTRIBUTES.Start_Time, 

LINK  ATTRIBUTES.End  Time,  LINK  ATTRIBUTES.Room ) 

StudentRoster  ;  set("  Student") 

StudentRoster  :=  students!  enrolled  in  Section!  Symbol  =  InputCourse _Section  ] 

and  oflfered  in  Quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ]  } 

for  index  in  first(StudentRoster) ..  last(StudentRoster)  loop 

Output!  StudentRoster!index]  .Last_Name,  StudentRoster!index]  .First_Name, 
StudentRoster!index]  .Middle_Initial,  StudentRoster!index] .  SS AN, 
StudentRoster!index]  .Program_Sequence_Code ) 

LINK  ATTRIBUTE  :=  TERNARY  RELATIONSHIPI  Student!  StudentRoster[index]  ], 
Quarter!  Term  =  InputTerm.  Term,  Year  =  InputTerm.  Year  ], 
Section!  LocalSection  ] 

Output!  LINKATTRIBUTE.Type ) 

LocalDegree  :  Degree  :=  degree!  pursued  by  Student!  StudentRoster!  index]  ] 

LocalQuarter  :  Quarter  :=  quarter!  graduates  Student!  StudentRoster!  index]  ] 

LINK  ATTR  :=  LINK  RELATIONSHIP!  Section!  ScheduledClasses!  index]]. 

Building!  LocalBuilding  ]  ] 

Output!  LocalDegree.ProgramCode,  LocalQuarter.  Year,  LINKATTR.  Symbol ) 


end  loop 
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Assi2n  Student  Academic  Advisor  Form; 


Student: 

Last  Name.  First  Name _ MI  SSAN _ Rank _ Graduation  Code 


Academic  Advisor: 

Last  Name _ First  Name _ mi _ SSAN _ Rank _ Department 


Figure  A.29  Assign  Student  Academic  Advisor  Object  Model 


Algorithm  to  construct  assign  student  academic  advisor  form  from  object  diagram: 

Build  assign  student  academic  advisor  form  on  student  identification.  Input  Student's  social  seciuity 
account  number.  (Note;  Similar  procedures  followed  given  instructor's  identification.) 

Obtain  Instance  of  Student. 

Output  Student's  Last  Name,  First  Name,  Middle  Initial,  SSAN,  and  Rank. 

Traverse  Student-Degree  pursues  association  to  obtain  instance  of  Degree. 

Output  ProgramCode. 

Traverse  Student-Quarter  graduates  association  to  obtain  instance  of  Quarter. 

Output  Year  and  link  attribute  Symbol. 

Traverse  Student-Faculty  advises  association  to  obtain  instance  of  Faculty 
Output  Faculty's  Last  Name,  First  Name,  Middle  Initial,  SSAN,  and  Rank. 

(With  Faculty  instance)  Traverse  Faculty-Department  association  for  instance  of  Department 
Output  Department  Name. 
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SQL  versus  OQL  Comparison 


Assume  input  from  user  is  InputSSAN  (Student's  SSAN). 

Assume  following  relational  tables  exist: 

Faculty_Civilian(  SSAN,  Occupation_Series_Code ) 

Faculty_History(  SSAN,  Academic  Rank  Code ) 

Faculty_Type_Valid(  FacultyTypeCode,  FacultyType ) 

Rank_History(  SSAN,  Grade  R^  Abbrev ) 

Person(  SSAN,  First  Name,  Last  Name,  Middle  lnitial,  Department  Code ) 

Resident_Student(  SSAN,  Class_Code,  Faculty_Advisor_SSAN ) 

Pseudo-code  (with  SQL)  to  construct  assign  advisor  to  student  with  identification. : 

create  view  View_Person_Resident(  SSAN,  Last  Name,  First  Name,  Middle  lnitial, 
Class_Code,  FacultyAdvisorSSAN )  as 

( select  Person.  SSAN,  Last  Name,  First  Name,  Middle  lnitial,  Class  Code, 

FacultyAdvisorSSAN 

from  Person,  Resident  Student 

where  Person.  SSAN  =  Resident_Student.SSAN ) 

select  First_Name||'  '||Middle_Initial||'  '||Last_Name,  Class  Code,  SSAN,  Grade_Rank_Abbrev, 
Faculty_Advisor_SSAN 

into  Name,  Class_Code,  SSAN,  Rank,  Advisor_SSAN 
from  View_Person_Resident,  Rank  History 
where  View_Person_Resident.SSAN  =  InputSSAN 
and  View_Person_Resident.SSAN  =  Rank_History.SSAN 

Output(  Name,  SSAN,  Rank,  Class_Code ) 

select  SSAN,  Last  Name,  First  Name,  Middle  lnitial,  Department_Code, 
AcademicRankCode 

into  SSAN,  Last  Name,  First  Name,  Middle  lnitial,  Department,  Academic  Rank 
from  Person,  Faculty  Histoiy 
where  Person.SSAN  =  Faculty_History.SSAN 
and  Person.SSAN  =  Advisor  SSAN 

Output(  Last_Name,  First  Name,  Middle  lnitial,  SSAN,  Department ) 

select  Faculty_Type 

from  Faculty_Type_Valid 

where  Faculty  Type  Code  =  Academic  Rank 

if  Faculty_Type  is  Military  then 

select  Grade_Rank_Abbrev 
into  Rank 

from  Person,  Rank  History 
where  Person.  SSAN  =  Rank  History.SSAN 
and  Person.SSAN  =  Faculty  Advisor  SSAN 
Output(  Rank ) 

else 

select  OccupationSeriesCode 
into  Rank 
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from  Person,  Faculty  Civilian 
where  Person.  S  SAN  =  Faculty  Civilian.SSAN 
and  Person.  SSAN  =  FacuIty  Advisor  SSAN 
Output(  Rank ) 

end  if 

Pseudo-code  (with  proposed  OQL)  to  construct  assign  advisor  to  student  with  id: 

Assume  input  from  user  is  InputSSAN  (Student's  SSAN). 

select  distinct  LocalStudent 
from  X  in  Students 
where  x.SSAN  =  InputSSAN 

Output(  LocalStudent.Last  Name,  LocalStudent.First_Name,  LocalStudent.Middle  lnitial, 
LocalStudent.  SSAN,  LocalStudent.Rank ) 

select  distinct  LocalDegree 
from  X  in  Students 
y  in  x.pursues 

where  x.SSAN  =  InputSSAN 

select  distinct  LocalQuarter 
from  X  in  Students 
y  in  X.  graduates 
where  x.SSAN  =  InputSSAN 

select  ATTRIBUTE 

from  X  in  Students 
y  in  X.  graduates 
where  x.SSAN  =  InputSSAN 

Output(  LocalDegree.Program  Code,  LocalQuarter. Year,  ATTRIBUTE.  Symbol ) 

select  distinct  LocalFaculty 
from  X  in  Students 

y  in  x.advisedby 
where  x.SSAN  =  InputSSAN 

Output(  LocalFaculty.LastName,  LocalFaculty.FirstName,  LocaIFaculty.Middle_Initial, 
LocalFaculty.  SSAN,  LocalFaculty.Rank ) 

select  distinct  LocalDepartment 
from  X  in  Faculty 

y  in  x.assigned_to 
where  x  =  LocalFaculty 

Output(  LocalDepartment.Name ) 

Pseudo-code  (with  proposed  OQL)  to  assign  academic  advisor  to  student: 

Assume  input  from  user  is  (Student's  SSAN). 

LocalStudent  :  Student  :=  student[  SSAN  =  InputSSAN  ]  ] 
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Output(  LocalStudent.Last_Name,  LocalStudent.First_Name,  LocalStudent.Middle_Initial, 
LocalStudent.SSAN,  LocalStudent.Rank ) 

LocalDegree  :  Degree  ;=  degree[  pursued  by  Student[  LocalStudent  ] 

LocalQuarter  :  Quarter  :=  quarter[  graduates  Student[  LocalStudent  ] 

ATTRIBUTE  :=  LINK_RELATIONSHIP[  Student[  LocalStudent  ], 

Quarter[  LocalQuarter  ]  ] 

Output(  LocalDegree.Program  Code,  LocalQuarter. Year,  ATTRIBUTE.  Symbol ) 

LocalAdvisor  :  Faculty  ;=  faculty[  advises  Student[  LocalStudent  ]  ] 

Output(  LocalAdvisor.Last_Name,  LocalAdvisor.FirstName,  LocalAdvisor.Middlelnitial, 
LocalAdvisor.  SS  AN,  LocalAdvisor.Rank ) 

LocalDepartment :  Department  :=  department[employs  Faculty[  LocalAdvisor  ] 

Output!  LocalDepartment.Name ) 
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AFIT  Course  Catalog; 

SCHOOL: 

Year  Quarter:  Dates  Inclusive 

CREDIT  ACTIVITY  MAX  NOTES 

COURSE  TITLE _ HOURS  TYPE  ENROLL  CODE 


Figure  A.30  AFIT  Course  Catalog  Object  Model 


NOTES 
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Student  Transcript: 


STUDENT  NAME  rLAST  NAME.  FIRST  SSAN  PROGRAM  CLASS  CODE  ADVISOR 

QUARTER  YEAR 

COURSE  TITLE _ INSTRUCTOR _ CREDIT  HRS  GRADE  POINTS 

QUARTER  HOURS  QUARTER  GPA  CUMULATIVE  HOURS  CUMULATIVE  GPA 


offered_by  offers 


Figure  A.31  Student  Transcript  Object  Model 


A-35 


Person  Structure  Definition 


Object  Name:  Person 
Object  Number: 

Object  Description:  General  model  of  a  person 


Date:  07/28/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  None 

Components:  None 

Context:  None 


Attributes: 

lastname 

String 

firstname 

String 

initial 

character 

nameprefix 

prefix  type 

namesuffix 

suffix  type 

ssan 

String 

gender 

{male,  female} 

birthdate 

date  type 

loginname 

String 

logindate 

date  type 

Constrsunts: 

Person’s  last  name. 

Person’s  first  name. 

Person’s  middle  initial. 

Person’s  name  prefix. 

Person’s  name  suffix. 

Social  Security  Account  Number. 

Date  of  birth. 

Person’s  computer  login  name. 
Date  of  last  activity. 


Z  Static  Schema: 

Let  SSAN_TYPE  be  the  set  of  all  Social  Security  Account  Numbers. 
Let  DATE_TYPE  be  the  set  of  all  possible  dates. 

Let  PREFIX-TYPE  be  the  set  of  all  possible  name  prefixes. 

Let  SUFFIX— TYPE  be  the  set  of  all  possible  name  suffixes. 


_ Person _ 

lastname  :  String 

firstname  :  String 

initial :  Character 

nameprefix  :  PREFIX-TYPE 

namesuffix  :  SUFFIX— in' PE 

ssan  :  String 

gender  :  {male,  female} 

birthdate  :  DATE-TY PE 

loginname  :  String 

logindate  :  DATE-TYPE 
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Faculty  Structure  Definition 


Object  Name:  Faculty 

Object  Number: 

Object  Description:  General  model  of  faculty  class. 

Date:  07/28/94 

History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Person 

Components:  None 

Context:  None 

Attributes: 

marital-statua 

{single,  married,  divorced} 

race 

race  type 

Race. 

ethnic-group 

ethnic  type 

Ethnicity. 

religion 

religion  type 

Religion. 

badge— number 

badge  number  type 

Badge  number. 

duty-phone 

phone  type 

Duty  telephone  number. 

duty-oddress 

address  type 

Duty  address. 

home-phone 

phone  type 

Home  telephone  number. 

home-oddress 

address  type 

Home  address. 

e  —  mail-address 

String 

Electronic  mail  address. 

academic-odvisees 

Person  set  type 

set  of  pointers  to  students. 

thesis-odvisees 

Person  set  type 

set  of  pointers  to  students. 

academic-rank-date 

date  type 

date  of  academic  rank. 

academic-rank-code 

academic  rank  type 

academic  rank. 

academic-step 

academic  step  type 

academic  step. 

Constraints: 


Z  Static  Schema: 

Let  RACE-TYPE  be  the  set  of  all  r2ice  types. 

Let  ETHNIC-TYPE  be  the  set  of  all  ethnic  types. 

Let  RELIGION-TYPE  be  the  set  of  all  religions. 

Let  BADGE-NUMBER— TYPE  be  the  set  of  all  possible  badge  numbers. 
Let  PHONE-TYPE  be  the  set  of  all  possible  phone  numbers. 

Let  ADDRESS-TYPE  be  the  set  of  all  valid  addresses. 

Let  PERSON-PTR—TYPE  be  a  pointer  to  a  particular  person. 

Let  PERSON-PTR-SET-TYPE  be  a  set  of  pointers  to  particular  people. 
Let  COURSE-PTR— SET-TYPE  be  a  set  of  pointers  to  a  quarter’s  courses. 
Let  ACADEMIC-RANK-TYPE  be  a  set  of  valid  academic  ranks. 

Let  ACADEMIC— STEP-TYPE  be  a  set  of  valid  academic  steps. 
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F  acuity _ 

marital-status  :  {single,  married,  divorced} 
race  :  RACEJTYPE 
ethnic-group':  ETHNIC-TYPE 
religion  :  RELIGION-TYPE 
badge-number  :  BADGE-NUMBER-TYPE 
duty-phone  :  PHONEJTYPE 
duty-oddress  :  ADDRESS-TY PE 
home-phone  :  PHONE-TYPE 
home-oddress  :  ADDRESS-TYPE 
e  —  mail-address  :  String 

academic-advisees  :  PERSON-PTR-SET-TYPE 
thesis-odvisees  :  PERSON-PTRSET-TYPE 
academic-rank-date  :  Person.D  ATE -TYPE 
academic-rank-code  :  ACADEMIC-RANK-TYPE 
academic-step :  ACADEMIC-STEP-TYPE 
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Student  Structure  Definition 


Object  Nrune:  Student 
Object  Number: 

Object  Description:  General  model  of  a  student 

Date:  07/28/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Person 

Components:  None 

Context:  None 

Attributes: 


marital^atatus 

{single,  married,  divorced} 

race 

race  type 

Race. 

ethnic-group 

ethnic  type 

Ethnicity. 

religion 

religion  type 

Religion. 

badge-number 

badge  number  type 

Badge  number. 

duty-phone 

phone  type 

Duty  telephone  number. 

duty-oddress 

address  type 

Duty  address. 

home-phone 

phone  type 

Home  telephone  number. 

hame-oddresa 

address  type 

Home  address. 

e  —  mail-oddreaa 

String 

Electronic  mail  address. 

academic-odviaor 

Person  Pointer 

Pointer  to  academic  advisor. 

theaia-odviaor 

Person  Pointer 

Pointer  to  thesis  advisor. 

theaia-readera 

Person  set  type 

set  of  thesis  readers. 

ed-plan 

quarter  set  type 

set  of  academic  quarters. 

quarter -achedule 

Course  Pointer  set 

set  of  pointers  to  courses. 

Constraints: 

Z  Static  Schema: 

Let  RACE-TYPE  be  the  set  of  all  race  types. 

Let  ETHNIC— TYPE  be  the  set  of  all  ethnic  types. 

Let  RELIGION— TYPE  be  the  set  of  all  religions. 

Let  BADGE— NUMBER— TYPE  be  the  set  of  all  possible  badge  numbers. 
Let  PHONE— TYPE  be' the  set  of  all  possible  phone  numbers. 

Let  ADDRESS— TYPE  be  the  set  of  all  valid  addresses. 

Let  PERSON— PTR— TYPE  be  a  pointer  to  a  particular  person. 

Let  PERSON— PTR— SET— TYPE  be  a  set  of  pointers  to  particular  people. 
Let  QUARTER— SET— TYPE  be  a  set  of  pointers  to  academic  quarters. 

Let  COURSE— PTR— SET— TYPE  be  a  set  of  pointers  to  a  quarter’s  courses. 
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Student _ 

marital-status  :  {single,  married,  divorced} 
race  :  RACEJTYPE 
ethnic-group':  ETHNIC-TYPE 
religion  :  RELIGION-TYPE 
badge-number  :  BADGE-NUMBER-TYPE 
duty-phone  :  PHONEJTYPE 
duty-address  :  ADDRESS-TY  PE 
home-phone  :  PHONE-TYPE 
home-address :  ADDRESS-TY  PE 
e  —  mail-address  :  String 
academic-odvisoT  :  PERSON-PTR—TY  PE 
thesis-odvisor  :  PERSON-PTR—TY  PE 
thesis-readers  :  PERSON-PTR— SET -TYPE 
ed-plan :  QUARTER-SET-TYPE 
quarter-schedule  :  COU RSE-PTR—SET-TY PE 
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MilitaryFaculty  Structure  Definition 


Object  Name:  MilitaryFaculty 
Object  Number: 

Object  Description:  General  model  of  a  military  faculty 

Date:  07/29/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Faculty 

Components:  None 

Context:  None 

Attributes: 


rank 

rank  type 

Military  rank. 

branch 

branch  type 

Branch  of  service. 

dateofrank 

date  type 

Date  of  rank. 

AFSC 

AFSC  type 

AFSC  code. 

aeroratingcode 

rating  type 

Aero  rating. 

dateof  commission 

date  type 

Date  of  commission. 

dateo  f  separation 

date  type 

Date  of  separation. 

manningcode 

DEROSdate 

date  type 

Constraints: 

Z  Static  Schema: 

Let  RANK-TYPE  be  the  set  of  military  rank  types. 

Let  BRANCH— TYPE  be  the  set  of  all  armed  service  branches  types. 
Let  DATE— TYPE  be  the  set  of  all  dates. 

Let  APSC— TYPE  be  the  set  of  all  possible  AFSC  codes. 

Let  AERO-RATING-TYPE  be  the  set  of  all  aero  ratings. 


M  ilitary  Faculty _ 

rank  ;  RANKJTYPE 

branch :  BRANCH-TYPE 

dateofrank  :  DATE-TY PE 

AFSC  :  AFSCJTYPE 

aeroratingcode  :  AERO— RATING— TYPE 

dateof  commission  :  DATE-TY  PE 

dateof  separation  :  DATE-TYPE 

manningcode  : 

DEROSdate  : 
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CivilianFaculty  Structure  Definition 


Object  Name:  CivilianFaculty 
Object  Number: 

Object  Description:  General  model  of  a  civilain  faculty 

Date:  08/03/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Faculty 

Components:  None 

Context:  None 

Attributes: 

grade  grade  type  Civilian  grade. 

dateof  grade  date  type  Date  of  grade. 

manningcode 
DEROSdate  date  type 

Constraints: 

Z  Static  Schema: 

Let  GRADE-TYPE  be  the  set  of  civilain  grade  types. 
Let  DATE-TYPE  be  the  set  of  all  dates. 


A-42 


CivilianStudent  Structure  Definition 

Object  Name:  CivilianStudent 
Object  Number: 

Object  Description:  General  model  of  a  civilian  student. 

Date:  08/03/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Student 

Components:  None 

Context:  None 

Attributes: 

grade  grade  type  Civilian  grade. 

dateof  grade  date  type  Date  of  grade. 

manningcode 
DEROSdate  date  type 

Constraints: 


Z  Static  Schema: 

Let  GRADE-TYPE  be  the  set  of  civilain  grade  types. 
Let  DATE-TYPE  be  the  set  of  all  dates. 


CivilianStvdent _ 

grade  :  GRADE-TYPE 
dateof  grade  :  DATE-TYPE 
manningcode  : 

DEROSdate  : 
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MilitaryStudent  Structure  Definition 


Object  Name:  MilitaryStudent 
Object  Number: 

Object  Description:  General  model  of  a  military  student 

Date:  07/29/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Student 

Components:  None 

Context:  None 

Attributes: 


rank 

rank  type 

Military  rank. 

branch 

branch  type 

Branch  of  service. 

dateofrank 

date  type 

Date  of  rank. 

AFSC 

AFSC  type 

AFSC  code. 

aeroratingcode 

rating  type 

Aero  rating. 

dateof  commission 

date  type 

Date  of  commission. 

dateof  separation 

date  type 

Date  of  separation. 

manningcode 

DEROSdate 

date  type 

Constraints: 

Z  Static  Schema: 

Let  RANK-TYPE  be  the  set  of  military  rank  types. 

Let  BRANCH-TYPE  be  the  set  of  all  armed  service  branches  types. 
Let  DATE— TYPE  be  the  set  of  all  dates. 

Let  AFSC— TYPE  be  the  set  of  all  possible  AFSC  codes. 

Let  AERO-RATING-TYPE  be  the  set  of  all  aero  ratings. 


MilitaryStudent - 

r-onifc  :  RANK-TYPE 

branch :  BRANCH-TYPE 

dateofrank  :  DATE-TY  PE 

AFSC  :  AFSCJTYPE 

aer  orating  code  :  AERO-RATING-TYPE 

dateof commission  :  DATE-TYPE 

dateof  separation  :  DATE— TYPE 

manningcode  : 

DEROSdate  : 
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InternationalStudent  Structure  Definition 


Object  Name:  InternationalStudent 
Object  Number: 

Object  Description:  General  model  of  an  international  student. 

Date:  08/03/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Student 

Components:  None 

Context:  None 

Attributes: 

WSCN  WSCN  type 
ITO 


Constraints: 


Let  WSCN_TYPE  be  the  set  of  WSCN  types. 
Let  DATE-TYPE  be  the  set  of  all  dates. 


_ Inter  national  Strident _ 

WSCN  :  WSCN-TYPE 
ITO  : 
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Course  Structure  Definition 


Object  Name:  Course 
Object  Number; 

Object  Description:  General  model  of  an  AFIT  course  class. 

Date:  07/29/94 
History;  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  None 

Components:  None 

Context:  None 

Attributes: 


prefix 

String 

Course  prefix. 

number 

integer 

Course  number. 

section 

character 

Course  section. 

title 

String 

Course  title. 

instructor 

Person  pointer 

Pointer  to  instructor. 

students 

Person  pointer  set 

Set  of  pointers  to  students. 

instructor  contacthr 

integer 

Class  time. 

lahcont<icthours 

integer 

Lab  time. 

miner  edit  hours 

integer 

minimum  credit  hours. 

maxcredithours 

integer 

maximum  credit  hours. 

class  starttime 

time  type 

Time  class  starts. 

classendtime 

time  type 

Time  class  ends. 

classmeeting  days 

day  type  set 

Set  of  days  class  meets. 

classroom 

Room  pointer 

Pointer  to  classroom. 

labstarttime 

time  type 

Time  lab  starts. 

labendtime 

time  type 

Time  lab  ends. 

labmeeting  days 

day  type 

Day  lab  meets. 

labroom 

Room  pointer 

Pointer  to  lab. 

term 

term  type 

Term  scheduled. 

quarter 

quarter  type 

Quarter. 

yearprefix 

Year  type 

Year  prefix. 

Constraints: 

Z  Static  Schema: 
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Let  PERSON—PTR  be  a  pointer  to  a  person. 

Let  PERSON_PTR_SET  be  the  set  of  pointers  to  people. 
Let  TIME  be  the  data  type  of  all  valid  times. 

Let  DAY-SET  be  a  set  of  days. 

Let  ROOM-PTR  be  a  pointer  to  a  room. 

Let  DAY-TYPE  be  a  data  type  for  days. 

Let  TERM-TYPE  be  a  data  type  for  academic  term. 

Let  QUARTER— TYPE  be  a  data  type  for  academic  quarter. 
Let  YEAR— TYPE  be  a  data  type  for  year. 


_ Course _ 

prefix  :  Siring 
number  :  U 
section  :  character 
title  :  String 

instructor  :  PERSON -PTR 
students  ;  PERSON-PTR^ET 
instructoT-contact-hr  :  M 
lab^contact-hours  :  M 
min-cr edit-hours  :  M 
max-cr edit-hours :  M 
class-start-time  '.TIME 
class-end-time  :  TIME 
class-meeting-days  :  DAY-SET 
classroom  :  ROOM-PTR 
lab— start-time  -.TIME 
lab-end-time  :  TIME 
lab-meeting-days  :  DAY-TY PE 
lab-room ;  ROOM-PTR 
term :  TERM-TY PE 
quarter  :  QUARTER-TYPE 
year-prefix  :  Y EARtY PE 
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Book  Structure  Definition 


Object  Name:  Book 
Object  Number: 

Object  Description:  General  model  of  a  book  class. 

Date:  07/29/94 
History:  Thesis 


Author:  Capt  Douglas  Wu 
Superclass:  None 


Components:  None 


Context:  None 


Attributes: 

title 

author 

copyrightyear 

publisher 

usedbycoursea 


String 

String 

integer 

String 

Course  pointer  set 


Book  title. 

Book  author. 

Book  copyright  year. 
Book  publisher. 

Set  of  pointers  to  course. 


Constraints: 


Z  Static  Schema: 

Let  COURSE_PTIL_SET  be  the  set  of  pointers  to  courses  requiring  book. 


_ Book - 

title  ;  String 
author  :  String 
copyright  :  M 
publisher  :  String 

uaedJby-Couraea  ;  COU RSE-PTRSET 
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Building  Structure  Definition 


Object  Name:  Building 
Object  Number: 

Object  Description:  General  model  of  a  building  class. 

Date:  08/03/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  None 

Components:  None 

Context:  None 

Attributes: 

name  String  Building  name. 

number  integer  Building  number. 

rooms  Room  pointer  set  Pointers  set  to  rooms  in  building. 

Constraints: 


Z  Static  Schema: 

Let  ROOM_PTR_SET  be  the  set  of  pointers  to  rooms  in  building. 


_ Building _ 

name  :  String 
number  :  Af 

rooms  :  ROOM-PTRSET 
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Room  Structure  Definition 


Object  Name:  Room 
Object  Number: 

Object  Description:  General  model  of  a  room  class. 

Date:  08/03/94 
History:  Thesis 

Author:  Capt  Douglas  Wu 

Superclass:  Building 

Components:  None 

Context:  None 

Attributes: 
number 
size 
seats 

chalkboard 
whiteboard 
viewgraphscreen 
viewgraphprojector 
usedbycourses 

Constrfunts: 

Z  Static  Schema: 

Let  DIMENSION-TYPE  be  a  pair  of  integers  (width  and  legnth)  of  a  room. 
Let  COURSE-PTR—SET  be  the  set  of  pointers  to  courses  requiring  book. 


integer 

dimension  type 

integer 

boolean 

boolean 

boolean 

boolean 

Course  pointer  set 


Room  number. 

Room  dimensions  in  feet. 
Number  of  seats. 


Set  of  pointers  to  course. 


_ Room _ 

number  :  M 

size  :  DIMENSION-TYPE 
seats  :  M 

chalkboard :  boolean 
whiteboard :  boolean 
viewgraphscreen  :  boolean 
viewgraphprojector  :  boolean 
used-by-courses  :  COU RSE-PTRSET 
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APPENDIX  B 


STARS  Relational  Tables  provided  by  Katherine  Hale,  16  June  1994 
Primary  keys  are  underlined  and  foreign  keys  emphasized. 

Academic_Action_Valid(  Academic  Action  Code.  Academic_Action,  Input_Date,  Login_Name ) 
Academic_Ed_Status_Valid(  Academic  Ed  Status  Code.  Academic_Ed_Status,  Input_Date, 
LoginName ) 

Acadeinic_Rank_Valid(  Academic  Rank  Code.  Academic  Rank,  Input_Date,  Login_Name ) 
Activity_Type_Valid(  Activity  Type  Code.  Activity_Type,  Login_Name,  Input_Date ) 

Address(  SSAN.  AddressJType  Code,  Firm  Name  Office  Symbol,  Additional  Address  Information, 
Street_ Address,  City,  State_Code,  Zipcode,  Zipcode_Extension,  Street  Type  Code, 

Address  Room  TypejCode,  Address_Room_Type_Number,  Area_Code,  Phone_Number, 
Address_Eflfective_Date,  DSN  Prefix,  Login  Name,  Revision_Name,  Revision  Date,  Country, 
Login  Date,  Address_Line_l,  Address_Line_2,  Address_Line_3,  Country  Code  ) 
Address_Room_Type_Code_Valid(  Address  Room  Type  Code.  Address_Room_Type_Code_Des, 

Input  Date,  Input  Name,  Revision  Date,  Revision  Name ) 

Address_Type_Valid(  Address  Type  Code.  Address  Type,  Input_Date,  Login_Name) 

Admission  Type  ValidtAdmission  Type  Code.  Admission  Type,  LoginName,  InputDate) 
AFIT_Degree_Valid(  AFIT  Degree  Code.  AFIT_Degree,  Input_Date,  Login_Name,  Type_Degree_Code, 
ABET_Accredited_Indicator ) 

AFSC_Valid(  AFSC  Code.  AFSC,  Enlisted_Indicator,  Input_Date,  Login_Name ) 

Award_Valid(  Award  Code.  Award,  Input_Date,  Login_Name ) 

Box_Number_Valid(  Box  Number.  Login_Name,  Input_Date ) 

Branch_Service_Valid(  Branch  Service  Code.  Branch_Service,  Input_Date,  Login_Name, 
MPC_Branch_Service_Abbrev ) 

Building_Valid(  Building  Code.  Building,  Input  Date,  Login  Name ) 

Career  Pointer  ValidtCareer  PointerCode.  Career  Pointer,  Input  Date,  Login  Name) 
Countries_Attending_AFIT  (  AFSAT  Country  Code.  Country,  Country  Count ) 

Country_VaIid(  Country  Code.  Country,  Login_Name,  Input  Date ) 

Course_Books(  Course  Prefix  Code.  Course  Number.  Course  Section.  Book ) 

Course  Books  UnofficiaKCourse  Prefix  Code.  Coiir.se  Number  Course  Section.  Book) 

Course  Coreqs  UnofficiaKCourse  Number.  Course  Prefix  Code.  Course  Section. 

Coreq_Eflfective_Date,  Coreq_Text,  Coreq_Text_Line_Number ) 

Course_Corequisites(  Course  Number.  Course  Prefix  Code.  Course  Section.  Coreq_Effective_Date, 
Coreq_Text,  Coreq_Text_Line_Number ) 

Course_Notes_UnoflaciaI(  Course  Number.  Course  Prefix  Code.  Course  Section.  Note_Code ) 
Course_Qfferings(  Course  Prefix  Code.  Course  Number.  Course  Section.  Course_TitIe, 

Projected_Sections,  ScheduleOOTerm  Code,  ScheduleOOQuarter  Code,  ScheduleJYear  Prefix, 
Exam  indicator,  Instructor_Contact_Hours,  Lab_Contact_Hours,  Min_Credit_Hours, 
Max_Credit_Hours,  Course  Offering  Status  Code,  CourseOODepartment  Code,  Remarks, 
InputDate,  LoginName ) 

Course_Offerings_Remarks(  ScheduleOOTerm  Code,  ScheduleOOQuarterjCode,  Schedule  Year  Prefix, 
CourseOODepartment  Code,  Remark,  Remark  Sequence  Number ) 

Course  Offering  InstructortCourse  Prefix  Code.  Course  Number.  Course  Section.  Faculty  SSAN. 
Course_TaughtOOTerm_Code,  Instructor_Load,  Course  TaughtOOQuarter  Code, 

Course  Taught  Year  Prefix,  Enrollment  Limit) 

Course_Offer_Status_Valid(  Course  Offering  Status  Code.  Course_Offering_Status,  Input_Date, 
Login_Name ) 
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Course_Prerequisites(  Course  Number.  Course  Prefix  Code.  Course  Section.  Prereq_EfFective_Date, 
Prereq_Text,  Prereq_Text_Line_Number ) 

Course_Prereq_Sub_Course(  Course  Prefix  Code,  Course  Number.  PrereqOOCourse  Number, 
PrereqOOCourse_Prefix_Code,  Prereq_SubOOCourse_Prefix_Code, 

Prereq  SubOOCourse  Number,  Prereq_Sub_Efifective_Date ) 

Course_Room_Requirements(  Course  Number.  Course  Prefix  Code.  Course  Section. 

Room  Requirement  Code ) 

Course_Unofficial(  Activity _Type  Code,  AFIT_School_Code,  CourseOODepartment  Code, 
Course_Effective_Date,  Course  Level  Code,  Course  Number.  Course  Prefix  Code- 
Course  Section.  Course  Title,  Credit  Check  Code,  Exam  indicator,  Individual  Contact  Hours, 
Input_Date,  Instructor  Contact  Hours,  Login  Name,  Max  Credit  Hours, 

Max  Eurollment  Limit,  Min  Credit  Hours,  Min  Enrollment  Liinit,  Releasibility  indicator, 
Special _Grading_Code,  Wait  List  Code,  GradingOODepartment  Code,  Lab_Contact_Hours, 
Full_Course_Title ) 

Degree  CandidatesC  SSAN.  Degree  Candidate  Date,  AFIT  Degree  Code  ) 

Department_Valid(  Department  Code.  Department,  Department_Head_SSAN, 

DirectorateOODepartment  Code,  Input_Date,  Login_Name,  RCCC  Code,  DSN_Phone  ) 
Dependent_Children(  SSAN.  Dependent  Child  Birth  Date,  Child_Last_Name,  Child  First  Name, 
Dependent  At _AFIT_lndicator,  ChildOOSex  Code  ) 

Dependent_Information(  SSAN.  Number  Children,  Sngle  Dep  Chldm  lndicator, 
DependentatAFITIndicator ) 

Distribution_Valid(  Distribution  Code.  Distribution,  Input  Date,  Login  Name ) 

Duty_History(  SSAN.  Duty_Effective_Date,  CBPO  Code,  MAJCOMjCode,  Org_Loc_Code,  Duty  Title, 
BasejCode,  DutyOOAFSCJCode,  Duty  Phone,  DSN  Phone,  DSN_Prefix,  Input_Date, 
Login_Name ) 

Edplan_Desc(  SSAN.  Career JPointerJCode,  Description,  Description_Line_Number ) 

Edplan_Errors(  Course  Prefix  Code.  Course_Number,  Coxu‘se_Section,  ScheduleOOTermjCode, 
Schedule  OOQuarterjCode,  Schedule _Year_Prefix ) 

Education_History(  SSAN.  Quality_Points,  Total_Credit_Hours,  MPC_School_Code,  ASCjOode, 
Method_Of_Obtainment_Code,  Academic_Ed_Status_Code,  Input_Date,  Operators_Initials, 
Login  Name,  Last_Year_Attended,  EdJevel  Code,  ABET  Accredited  Indicator, 
Ed_Histoiy_Remarks,  Work  ID  Processed  Code,  TrnscrptOOCareer_Pointer_Code, 
Type_Degree_Code,  Duty  Location  Code,  Degree  CUM  GPA,  Degree  Title ) 

Ed_Level_Valid(  Ed-  Level  Code.  Ed  Level,  Input  Date,  Login  Name ) 

Ethnic_Group_Valid(  Ethnic  Group  Code.  Ethnic  Group,  Login  Name,  Input  Date ) 
EvaIuation_By_School(  SSAN.  Admitted  indicator,  Evaluation  ResuIt  Remark, 

Evaluation  Forwarded  Date,  ForwardedJToOODepartment  Code,  EvaIuation_Retumed_Date ) 
EvaIuation_Status_Valid(  Evaluation  Status  Code.  Evaluation  Status,  Login  Name,  Input  Date ) 

Exam  ScheduletComse  Number.  Course  Prefix  Code.  Course  Section.  ExamOOTerm  Code, 

Exam  Date,  Exam  Time,  ExamOORoom  Code,  ExamOOBuilding  Code,  ExamOOQuarter  Code, 
ExamYearJPrefix) 

Exception(  SSMi,  Address  Type  Code,  Address  Linel,  Address_Line2,  Address_Line3) 
FacuIty_CiviIian(  SSAN.  Occupation  Series  Code  ) 

Faculty_History(  SSAN.  Academic_Rank_Date,  Academic  Rank  Code,  Academic_Step ) 
Faculty_Type_VaIid(  Faculty  Type  Code.  FacuIty  Type,  Input  Date,  Login  Name ) 
Fitness_Category_VaIid(  Fitness  Category  Code.  Fitness_Category,  Input  Date,  Login  Name, 
MeasurementUnit ) 

Fitness  PerformancefSSAN.  Fitness  Category  Code,  Elapsed  Time,  Trial  Date,  Input  Date, 
LoginName,  Distance ) 

Fitness_Standards_VaIid(  Low_Age_Range,  High  Age  Range,  Fitness  Category  Code.  SexJCode, 
Elapsed  Time,  Input_Date,  Login  Name,  Distance ) 

Funding(  SSAN.  Disbursement_Date,  Funding  Code,  Funding  Amount ) 

Funding_Valid(  Funding  Code.  Funding,  Input  Date,  Login  Name ) 
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Grade_Change_History(  SSAN.  Course  Prefix  Code.  Course  Number.  Course  Section. 

PriorOOGrade  Code,  ScheduleOOTerm  Code,  Grade_Effective_Date,  ScheduleOOQuarter_Code, 
Schedule _Year  Prefix ) 

Grade_History(  SSAN.  Approval  Code,  Approval  Date,  Career  Pointer  Code,  Credit  Hours, 

Eamed_Hours_Indicator,  GPA_Indicator,  Course  Prefix  Code,  Course  Number,  Input_Date, 
Course  Section,  ScheduleOOTerm  Code,  Grade  Code,  Grade  Type _Code,  Login_Name, 
PriorOOGrade  Code,  Grade  Effective  Date,  ScheduleOOQuarter  Code,  Schedule  Year  Prefix ) 
Grade_Type_To_Grade_Valid(  Grade  Type  Code.  Grade  Code,  Login  Name,  Input  Date ) 
Grade_Type_Valid(  Grade  Type  Code.  Grade  Code,  Login  Name,  Input  Date,  GPA  Indicator, 
EamedHoursIndicator ) 

Grade_Valid(  Grade  Code.  Grade,  Input  Date,  Login  Name,  Grade  Points,  GPA  Indicator, 
EamedHoursIndicator ) 

Graduation_Attendees(  SSAN.  GraduationOOTerm  Code,  GraduationOOQuarter  Code, 

Graduation  Year  Prefix ) 

Graduation_Date(  Graduation  Date,  Graduation_PIace,  GraduationOOTermjOode,  Login_Name, 
Input_Date,  GraduationOOQuarterjOode,  Graduation  Year  Prefix ) 

Grad_Audit(  Grad_Audit_Code,  Grade_Audit,  Input_Date,  Login  Name ) 

Grad_Status_VaIid(  Grade  Status  Code.  Grade_Status,  Login  Name,  Input_Date ) 

ID(ID) 

IntI_Sponsor(  Inti  Sponsor  SSAN.  IntI_Sponsor_Occupation,y4CCowJp_P7■e/erence_Co^/e, 
Avail_Start_Date,  Avail_End_Date ) 

IntI_Student(  SSAN.  WSCN,  ITO,  Case  Number,  DLI_Req_Indicator,  DLI  Indicator, 
Evaluation_Request_Date,  RequestedOOProgram  Code,  EvaI_Forward_Date, 
ForwardToOODepartmentjOode,  EvaI_Retumed_Date,  Admission _Status_Code,  EvaI_Remarks, 
Coimtry_Notified_Date,  AFSAT_Notified_Date,  AFSAT_Quota_Indicator,  First_Sponsor_SSAN, 
Second_Sponsor_SSAN,  Source _Of_Funds_Code,AFSAT_Country_Code ) 

Invention(  Invention,  Inventor.  Year,  Nation_Code ) 

TP  Activity  QbiectivesdP  Activity  Code.  IP_Objective_Code) 

IP_Activity_Valid(  IP  Activity  Code.  IP_Activity,  Login_Name,  Input_Date ) 

IP_Objective_Valid(  IP  Objective  Code.  IP_Objective,  Input_Date,  Login  Name ) 

IP_Resource(  IP  Activity  Code.  Activity_Address_l,  Activity_Address_2,  Activity_Address_3, 

Activity  City,  Activity  State,  Activity  Zipcode,  Activity  POC,  Activity_POC_Phone, 
Availability  Comment,  Activity  Evaluation,  POC  Area  Code,  Firm  Name  Office  SymboI, 
Additional  Address  Information,  Street_Address,  Street_Type_Code, 
Address_Room_Type_Code,Address_Room_Type_Number,  Activity_Zipcode_Extension, 
LoginName,  LoginDate,  RevisionName,  RevisionDate ) 

Job_TitIe_VaIid(  Job  Title  Code.  Job  Title,  Login  Name,  Input  Date ) 

Language_Valid(  Language  Code.  Language,  Input_Date,  Login_Name ) 

Leader  Valid!  Leader  Code.  Leader,  Login  Name,  Input  Date ) 

Letter_Status(  Letter  Status  Code.  Letter_Status,  Login_Name,  Input_Date ) 

Locker  ValidfLocker  Number.  Combination,  Locker  Size,  Login_Name,  Input_Date ) 

LS_Part_Time(  SSAN.  Pt  LS  StudentOOProgram  Code ) 

Mail  Building!  AFIT  School  Code.  Building  Code.  Login  Name,  Input  Date ) 

MAJCOM_Valid(  MAJCOM  Code.  MAJCOM_Abbrev,  MAJCOM,  Input_Date,  Login  Name ) 

Majors(  SSAN.  Career  Pointer  Code.  Major,  Login  Name,  Input_Date ) 

Majors_Valid(  Major,  Login_Name,  Input_Date ) 

Manning_Code(  Manning  Code.  Manning,  Login  Name,  Input_Date,  Branch  Service  Code  ) 
Marital_Status_Valid(  Marital  Status  Code.  Marital  Status,  Input  Date,  Login  Name ) 
Method_Of_Obtainment(  Method  Of  Obtainment  Code.  Method_Of_Obtainment,  Input_Date, 
LoginName ) 

Name_History(  SSAN.  Name_Change_Date,  First  Name,  Last  Name,  Middle  lnitial,  Name  Suffix, 
Name  Prefix,  Login  Name,  Marital  Status  Code  ) 
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Newsletter(  Addressee,  Address_Line_l,  Address_Line_2,  Address_Line_3,  City,  State_Code,  Zipcode, 
Zipcode  Extension,  Country  Code  ) 

New_Table(  SSAN.  AFSC ) 

Notes_Code(  Note  Code.  Note,  Login  Name,  Input  Date ) 

Occupation_Series_Valid(  Occupation  Series  Code.  Occupation  Series,  Login  Name,  Input_Date ) 
Options(  SSAN.  Career  Pointer  Code.  Options,  Login  Name,  Input_Date ) 

Options_Valid(  Options,  Login_Name,  Input  Date ) 

Person(  SSAN.  Grade_Rank_Abbrev,  Name_Prefix,  Name_Suffix,  First_Name,  Last_Name, 

Middlejnitial,  Birth_Date,  Sex  Code,  Race  Code,  Marital _Status_Code,  Religion  Code, 
Blue_Chip_Indicator,  Aka_FName,  Aka_LName,  Prior_AFIT_Months,  TAFMS_Date, 

Ethnic  Group  Code,  Aero  RatingjCode,  Manning  Code,  DEROS_Date,  Separation_Date, 
Commission  Code,  Grade  Rank  Date,  CitizenshipOOCountry  Code,  Department jCode, 

Duty  Title,  Duty_Phone,  Duty  Area  Code,  Badge  Number,  Branch  Service  Code, 

Login  Name,  Input  Date,  Duty  Phone  Ext ) 

Person_Job_TitIe(  SSAN.  Job  Title  Code ) 

Planes_Flown(  SSAN.  Plane_Name ) 

POC_Address(  Civilian  Jnstitution_Code,  School  In  Civ  Jns  Code,  POC_Type  JCode,  POC_Type_Seq, 
Department_Name,  Hospital_Firm_Name,  Street_Address,  Street _Type JCode, 
AddressRoomType JCode,  Room  JType  Number,  City,  State  JCode,  Zip,  Zip_Extension, 

Country  JCode,  Department_Entering_POC,  Dept_Entering_  Address,  Dept_Entering_POC, 
Login_Name,  Input_Date ) 

Prof  Military  Ed  ValidtPME  Level  Code.  PME  Description,  Login_Name,  Input  Date) 
Program_Advisor(  Program  Code.  Program  GraduationOOTerm  Code,  Class  Code, 
Program_Year_Prefix,  Program  Advisor  SSAN ) 

Program_Grad_Adit(  AuditOOProgram  Code.  Audit_EfFective_Date,  CourseJJumber, 

Course _Prefix JCode,  Grad jiudit JCode ) 

Program_Option(  Program  Code.  OptionOOProgram  Code,  Program_Option,  Input_Date,  Login_Name ) 
Program_Plan(  Program  Code.  ProgramGraduationOOTermCode,  Class  JCode,  Program_Year_Prefix, 
Course _Section,  Course _Number,  Course  Prefix _Code,  Credit_Hours,  EdPlanOOTerm JCode, 
EdPlanOOQuarter JCode,  EdPlan_Year_Prefix,  Input_Date,  Login_Name,  Course  JType  JCode  ) 
Program_Sections(  SectionNumber,  ProgramCode,  Program  jGraduationOOTerm JCode,  Class  JCode, 
Program_Year_Prefix ) 

Program_Sequences(  Program  Code.  Class  Code.  Year  Prefix.  Program _Sequence  JCode, 

Advisor OOSSAN,  Input  Date,  Login  Name  ) 

Program_Seq_Courses(  Program  Sequence  Code.  Prog  Seq  CoursesOOTerm  Code, 

ProgSeqCoursesOOQuarter JCode,  ProgSeqCoursesOOYear  Prefix,  Course  Prefix  JCode, 
Course  Number,  Course  _Section,  Grade  JType  Code,  CreditHours ) 

Program_Std_Sections(  SSAN.  Section  Number ) 

Race_Valid(  Race  Code.  Race,  Login  Name,  Input  Date ) 

Rank_History(  SSAN.  Grade_Rank_Date,  Grade  Rank  Abbrev,  Login  Name,  Input  Date, 

Manning  Code,  Branch  Service  Code ) 

Rank_Valid(  Pay  Type  Code.  Pay  Leyel  Code.  NCO  Indicator,  Rank  Code,  Rank, 

Branch  Seryice  Code.  Login  Name,  Input  Date,  MPC  Code,  Printed  Rank ) 

Recall_Roster(  SSAN.  Ho'me  Phone  Number,  Next  In  Chain  SSAN) 

Registration  Verification  (  SSAN.  Term  Code.  Quarter  Code.  Year  Prefix.  Registration  Notice ) 
Religion(  Religion  Code.  Religion,  Input_Date,  Login  Name ) 

Reselection(  Reselection  Code.  Reselection,  Input  Date,  Login  Name ) 

Resident_Student(  SSMi,  Academic jlctionCode,  Qyerduelndicator,  Classification  JCode, 
Part_Record_Indicator,  Admin_Hold_Indicator,  MajorOOASC  Code, 

Program  GraduationOOTerm  Code,  ClassCode,  Program  JYear_Prefix,  Selected  JType  Code, 
AFITJDegreeCode,  GraduationOOTerm  JCode,  GraduationOOQuarterCode, 
Graduation_Year_Prefix,  Grad  Status  Code,  Departure_Date,  Box  Number,  Card_Number, 
Encoded  Card  Number,  Library  Number,  Locker  Number,  Admit_Date, 
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Student  Sponsor  SSAN,  Entjry_Year_Prefix,  Admission  Type  Code,  Adinission_Action_Code, 
Career  Pointer _Code,  GainingOOAFSC  Code,  Faculty ^dvisor  SSAN, 
RegistrationOODepartment  Code,  Program  EffectiveOOTerm  Code,  EffectiveOOQuarter  Code, 
Effective  JTear  Prefix,  Leader J^ode,  Program_Section_Number,  GainOOMAJCOM_Abbrev, 
GainOODuty  Station,  LosingOOMAJCOM  Abbrev,  PSE  Code ) 

Resident_Student_Default(  Ed_Level_Code,  Classification  Code,  Grad  Status  Code, 

Admission  Type  Code,  Admin  Hold  lndicator,  Part  Record  Indicator,  Academic  Action  Code, 
Admission  Action  Code,  Overdue  indicator,  Career  Pointer  Code ) 

Room(  Building  Code,  Room  Code.  Room  Size,  Room  Remark,  Input  Date,  Login  Name  ) 
Room_Requirement(  Room  Code.  Building  Code,  Room  Requirement  Code ) 

Room_Reqiiirements(  Room  Requirement  Code.  Room  Requirement,  Login  Name,  Input  Date ) 
Room_Schedule(  Building  Code.  Room  Code.  Room  Start  Time,  Room  End  Time, 

Room  Schedule  Date,  Room  Schedule  Remark,  Room  Schedule  Contact ) 

Schedule(  Activity  fTypeJUode,  AFIT_School_Code,  Course_End_Date,  Course_End_Time, 

Course  Level  Code,  Course  Number.  Course  Prefix  Code.  Course  Section.  Course  Start  Date, 
Course_Start_Time,  Course_Title,  CourseOODepartment  Code,  Cedit  Check  Code,  DayjOode, 
Exam  indicator,  Individual  Contact  Hours,  Instructor  Contact  Hours,  Max  Credit  Hours, 
Max_Enrollment_Limit,  MinCreditHours,  MinEmollmentLimit,  Releasibilityindicator, 
ScheduleOOBuilding  Code,  ScheduleOORoom  Code,  ScheduleOOTermjCode, 

Special  Grading  Code,  Wait_List_Code,  ScheduleOOQuarter  Code,  Schedule fTear_Prefix, 
GradingOODepartmentCode) 

Schedule  MandatorvtMandatorv  Code.  Mandatory,  Login  Name,  Input_Date ) 

Schedule_Notes(  Course  Number.  Course  Prefix  Code.  Course  Section.  Note  Code. 

ScheduleOOTermjCode,  ScheduleOOQuarter  Code,  Schedule_Year_Prefix ) 
Schedule_Room_Requirements(  Course  Number.  Course  Prefix  Code.  Comse  Section. 

Room  Requirement  Code.  ScheduIeOOTerm_Code,  ScheduleOOQuarter_Code, 
Schedule_Year_Prefix) 

Schools(  MPC  School  Code.  School_Abbrev,  School,  State_Code,  City,  Input_Date,  Login_Name, 
CountryjOode ) 

School_In_Civ_Ins(  Civilian  Institution  Code.  School_In_Civ_Ins_Code,  School_Name,  Login  Name. 
Input_Date ) 

Section_Leaders(  SSAN.  Leader  Code.  Program  Code,  Class JCode,  Program_Section_Number ) 
Security  Class  ValidtSecuritv  Class  Code.  Security_Class,Login_Name,  Input  Date) 
Security_Clearance_Valid  (  Security  Clearance  Code.  Security  Description,  Input_Date,  Login  Name ) 
Selected_Comments(  SSAN.  Selected  Comment ) 

Selected_Projection(  SSAN.  GainOOMAJCOM  Code,  GainOOMAJCOM  Abbrev,  Gain_MAJCOM_ 
Supervisor,  Gain  MAJCOM  Supervisor  Phone,  Gain  MAJCOM  DSN  Prefix, 

Gain  MAJCOMOODepartment  Code,  Position  Nmnber  Projected ) 

Selected_Type(  Selected  Type  Code.  Selected  Type,  Input  Date,  Login  Name ) 

Sex(  Sex  Code.  Sex,  Input_Date,  Login  Name ) 

Source_Of_Funds_Valid(  Source_Of_Funds_Code,  Source  Of  Funds,  Login  Name,  Input  Date ) 
Special_Grading(  Special  Grading  Code.  Special  Grading,  Input  Date,  Login  Name ) 
Special_Sched_Request(  Approval  Code.  Approval  Date,  Course  Niunber,  Course_Prefix_Code, 

Course  Section,  Day  Code,  Faculty _SSAN,  Mandatory  Code,  Priority, 
Request_Alterhative_Number,  RequestEndTime,  RequestJustification,  Request_Start_Time, 
RequestOOActivity_Type_Code,  RequestOOBuilding  Code,  RequestOORoom  Code, 
RequestOOTermCode,  RequestOOQuarterCode,  RequestYearPrefix ) 
Sponsors_Country_Preference(  SSAN.  PreferredOOCountry  Code  ) 

Status_Change(  Status  Change  Code.  Status  Change,  Input  Date,  Login  Name ) 
Street_Type_Code_Valid(  Street  Type  Code.  Street_Type_Code_Description,  Input  Date,  Input  Name, 
Revision  Date,  Revision  Name ) 

Student_Duty_History(  SSAN.  Duty  Title,  DutyOOAFSC  Code,  Duty  Organization,  Duty  Station, 
Duty_Assigned_Date,  Login  Name,  Duty_Sequence_Number ) 
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Student_Sequences(  SSAN.  Program  Sequence  Code  ) 

Suspense_Calender(  Suspense  Code.  FromOODepartment_Code,  ToOODepartment  Code,  Suspense_Date, 
Term  Code,  Quarter  Code,  Year  Prefix ) 

Suspense_User_Class(  Suspense  Code.  Security_Class_Code,  Username ) 

Suspense_Valid(  Suspense  Code,  Suspense,  Login  Name.  Input  Date ) 

Swim_Times(  SSAN.  Eflfective  Date,  Swim  Time ) 

TDY  AttendeesCSSAN.  Left_For_TDY_Date,  Retumed_From_TDY_Date,  TDY  Destination  Code, 
TDYPurpose ) 

TDY_Destination_Valid(  TDY  Destination  Code,  TDY  Destination,  Lopin  Name  Input  Date ) 

Terms(  Term  Code.  Term,  Login_Name,  Input  Date,  Quarter  Code,  Class  Code,  Year  Prefix ) 
Term_Date(  Term  Code.  Term  Start  Date,  Term  End  Date,  Input  Date,  Login  Name, 
Regs_CutofF_Date,  Quarter  Code,  Year  Prefix,  Offering  Cutoff  Date, 

Grad  Stud  Grades  Cutoff  Date,  Nongrad  Grades  Cutoff  Date,  Thesis  Cutoff  Date, 

School  Schedule  Start  Date,  School  Schedule  End  Date ) 

Term_Entry(  SSAN.  Entry 00Term_Code,  EntryOOQuarter  Code,  Entry  Year  Prefix, 

Admission  Type  Code,  Admission  Action  Code  ) 

Term_Entry_History(  SSAN.  EntryOOTerm  Code,  EntryOOQuarter  Code,  Entry _Year  Prefix, 

Admission  TypejOode,  Admission  Action  Code ) 

Test_Type(  Test  Type  Code.  Test  Type,  Login  Name,  Input_Date,  Maximum_Score ) 

Thesis_Sponsor(  Thesis  Sponsor  Code.  Thesis  Sponsor,  Sponsor  POC,  DSN  Prefix, 
ThesisSponsorPhone ) 

Thesis_Title(  Thesis  Piss  Key.  Thesis  Title,  Thesis  Sequence  Number ) 

Wait_List(  SSAN.  Course _Prefix_Code,  Course  Number,  Course _Section  ) 

Wait_List_Types(  Wait  List  Code.  Wait  List,  Login  Name,  Input_Date ) 

Waived_Course(  SSAN.  WaivedOOCourse_Prefix_Code,  WaivedOOCourse_Number, 
WaivedOOGrade_Code,  Waived_Date ) 
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APPENDIX  C 


LIST  OF  ABBREVIATIONS 

AFIT  -  Air  Force  Institute  of  Technology 

AFITSIS  -  Air  Force  Institute  of  Technology  Student  Information  System 

BNF  -  Backus  Naur  Form 

CAD  -  Computer-Aided  Design 

CASE  -  Computer-Aided  Software  Engineering 

CCQ  -  AFIT  orderly  room 

DAGSI  -  Dayton  Area  Graduate  Studies  Institute 

DBMS  -  Database  Management  System 

DFD  -  Data  Flow  Diagram 

ISA  -  International  Student  Affairs 

LOC  -  lines  of  code 

ODMG-93  -  Object  Database  Management  Group 

ODBMS  -  Object- Database  Management  System 

ODL  -  Object  Data  Language 

ODD  -  Object  Identifier 

OMT  -  Object  Modeling  Technique 

OODBMS  -  Object-Oriented  Database  Management  System 

OQL  -  Object  Query  Language 

QUEST  -  Quota  Education  and  Selection  Transactions 

RDBMS  -  Relational  Database  Management  System 

SQL  -  Structured  Query  Language 

STARS  -  Student  Tracking  and  Registration  System 

C-1 


Bibliography 


1 .  Ahmed,  Shamin,  Albert  Wong,  Duwuru  Sriram,  and  Robert  Logcher.  "Object- 
Oriented  Database  Management  Systems  for  Engineering;  A  Comparison,"  Journal  of 
Object-Oriented  Programming.  June  1992.  pp.  27-44. 

2.  Atwood,  Thomas.  "The  Case  for  Object-Oriented  Databases,"  IEEE  Spectrum. 
February  1991,  pp.  44-47. 

3.  Atwood,  Thomas.  "ODMG-93:  The  Object  DBMS  Standard,  part  2,"  Object 
Magazine.  January  1994,  pp.  32-37. 

4.  Bertino,  Elisa  and  Lorenzo  Martino.  "Object-Oriented  Database  Management 
Systems:  Concepts  and  Issues,"  IEEE  Computer.  April  1991.  pp.  33-47. 

5.  Cattell,  R.G.G.,  Tom  Atwood,  Joshua  Duhl,  Guy  Ferran,  Mary  Loomis,  Drew  Wade. 
The  Object  Database  Standard:  ODMG-93.  Morgan  Kaufinann  Publishers,  Inc,  1994. 

6.  Cemey,  Caroline.  AFIT/SCQ  Personal  Interview,  April  1994. 

7.  Coad,  Peter  and  Edward  Yourdon.  Object-Oriented  Design.  Yourdon  Press,  1991. 

8.  Cohen,  Norman.  Ada  as  a  Second  Language.  McGraw-Hill  Book  Company,  1986. 

9.  Davis,  Richard.  Thesis  Projects  in  Science  and  Engineering.  St.  Martin's  Press,  1980. 

10.  Feldman,  Michael,  and  Elliot  Koffinan.  Ada:  Problem  Solving  and  Program  Design. 
Addison-Wesley  Publishing  Company,  1993.  pp.  1-795. 

11.  Hale,  Katherine.  AFIT/SCQ  Personal  Interview,  April  1994. 

12.  Hartrum,  Thomas  and  Paul  Bailor.  A  Formal  Extension  to  00 A  (Unpublished).  Air 
Force  Institute  of  Technology,  April  1993.  pp.  1-70. 

13.  Joseph,  John,  Satish  Thatte,  Craig  Thompson,  and  David  Wells.  "Object-Oriented 
Databases:  Design  and  Implementation".  Proceedings  of  the  IEEE.  Vol.  79.  No.  1, 
January  1991.  pp.  42-64. 

14.  Kim,  Won.  "A  New  Database  For  New  Times".  Datamation:  35-42.  15  January 
1990. 


BIB-1 


15.  Kim,  Won.  "Defining  Object  Databases  Anew".  Datamation:  33-36.  1  February 

1990. 

16.  Korth,  Henry,  and  Abraham  Silberschatz.  Database  System  Concepts.  Second 
Edition.  McGraw-Hill,  Inc.,  1991. 

17.  Nyberg,  Karl.  The  Annotated  Ada  Reference  Manual.  2nd  Edition.  Grebyn 
Corporation,  1991.  pp.  1-500. 

18.  Rasmus,  Daniel.  "Relating  to  Objects".  Byte:  161-165.  December  1992. 

19.  Rumbaugh,  James  and  others.  Object-Oriented  Modeling  and  Design.  Prentice-Hall, 

1991. 

20.  Itasca  LISP  API  User  Manual  for  Release  2,2.  Itasca  Systems,  Inc.,  1993. 

21.  STARS  User's  Manual  (AFIT  Database^.  Systems  Research  Laboratories,  1987. 


BIB-2 


Vita 


Captain  Douglas  James  Wu  was  bom  in  Springfield,  Vermont  on  22  July  1967. 
He  graduated  from  Black  River  High  School  in  Ludlow,  Vermont  in  1985.  He  attended 
the  Military  School  of  Vermont,  Norwich  University,  where  he  was  awarded  the  degree  of 
Bachelor  of  Science  in  Electrical  Engineering  in  May  of  1989.  After  commissioning 
through  Reserve  Officers  Training  Corps,  he  was  assigned  to  the  Ballistic  Missile 
Organization,  Norton  AFB,  San  Bemadino,  CA  where  he  was  the  Intercontinental 
Ballistic  Missile  Trainer  Software  Project  Manager  for  the  Rapid  Execution  and  Combat 
Targeting  modification  program.  In  May  1993  Captain  Wu  entered  the  Air  Force  Institute 
of  Technology  as  a  Masters  candidate  in  computer  systems. 


Permanent  address:  48  Andover  Street 

Ludlow,  Vermont  05149 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  buroen  for  tnis  coneaion  of  mformatton  is  estimated  to  ax^erage  i  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information.'incluamc  suggestions  for  reducing  this  Durden,  to  Washington  Headquarters  Services,  Direaorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Hiahway.  Suite  1204.  Ariinaton,  VA  22202-4302.  and  to  the  Office  of  Management  and  Budget.  Paperwork  Reduction  Project  (0704-0188).  Washington,  DC  20503. 


1.  AGtNCY  USE  ONLY  (Leave  blank) 


2.  REPORT  DATE 

December  1994 


3.  REPORT  TYPE  AND  DATES  COVERED 

Master’s  Thesis 


4.  TITLE  AND  SUBTITLE 

The  Re-Engineering  of  the  Air  Force  Institute  of  Technology 
Student  Information  System 


6.  AUTHOR(S) 

Douglas  J.  Wu 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6583 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

AFIT/GCS/ENG/94D-27 


S.  SPONSORING /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES} 


10.  SPONSORING /MONITORING 
AGENCY  REPORT  NUMBER 


I  12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 


12b.  DISTRIBUTION  CODE 


Distribution  Unlimited 


AS.S1RAC7  (Maximum  200  wards)  .  . 

This  research  describes  the  design  and  implemetation  issues  associated  with  re-engineering  the  Air  Force  Insti¬ 
tute  of  Technology  Student  Information  System  (AFITSIS).  Currently,  AFITSIS  executes  on  aging  relational 
database  technology  and  has  unfriendly  user  interface  mechanisms.  The  two  research  objectives  met  were  to 
research  current  AFITSIS  requirements,  design,  and  implementation,  and  use  object-oriented  methods  to  de¬ 
sign  an  alternative  implementation  based  on  proposed  object  database  management  system  standards.  This 
research  explores  how  AFITSIS  performance  and  capabilities  might  be  enhanced  by  taking  advantage  of  new 
object-oriented  software  engineering  techniques.  One  of  the  primary  benefits  of  this  research  is  a  detailed  object 
modeling  technique  analysis  and  design  that  may  be  used  as  a  foundation  for  upgrading  the  current  AFITSIS. 


14.  SLiC.'FCT  Ti-Rl.';.'  ...  .  t  ^'5.  NUMBER  OF  PAGES 

AFiTSIS,  AFIT  Student  Information  System,  information  system  design,  OODBMS  i  142 

Design,  ODBMS  Design,  Database  OMT  h6~’pRiCE'cdD-  . . 


I  17.  SECURITY  CLASSIFICATION 

OF  REPORl 

i  18.  SECUPdTY  CLASSIFICATION 
[  OF  THIS  PAGE 

I  15.  SECURITY  CLASSIFICATION 
[  OF  AESTP,ACT 

j  20.  LIMITATION  OF  ABSTRACT 

UNCLASSIFIED 

[  UNCLASSIFIED 

I  UNCLASSIFIED 

I  UL 

I 


MSN  7540-01-280-5500 


Standard  Forrri  29S  (Rev.  2-89) 

bv  AnS:  '.;c  Z39-’E 


